1 / 5

General Requirements (v2)

General Requirements (v2). status: working group last call (2/10) change: IEprep to IEPREP. IP Telephony Requirements (v2). status : working group last call (2/10) Issue:

lallen
Télécharger la présentation

General Requirements (v2)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. General Requirements (v2) • status: working group last call (2/10) • change: • IEprep to IEPREP

  2. IP Telephony Requirements (v2) • status : working group last call (2/10) • Issue: • concern about the term application layer mechanisms “able to support better than best effort” for application layer signaling carrying ETS labels • suggested change to “other than best effort” • Change: • “…other than best effort (we assume this to be better than best effort)”

  3. Status: version 4 not last call Changes from list: don’t refer to VoIP as “..other elastic application..” change “carriers” to “telephony carriers” expand the reference of “higher probability” to refer to call completion removed term “centralized authentication” in reference to PSTN security model Suggested Additions…TBD refer to Genuity & Sprint TE discussed in Atlanta IETF discuss suggestion of service that makes a positive difference original comment aimed at General Requirements More to be added?? DCCP spec due in Dec ‘03 NSIS UDP-Lite IP Telephony Framework, v4

  4. New IP Telephony Req “5) With respect to application layer signaling, Application-layer mechanisms specifically targeted to recognize ETS type labels MUST be ABLE to support a service other than best effort (we assume this to be better than best effort service). This support SHOULD focus on probability of forwarding packets used for call completion. Probability MAY reach 100% depending on the local policy associated with the label. Local policy MUST also be used to determine IF better than best effort is to be applied to a specific label (or related set of labels). The above paragraph MUST be taken in its entirety. The ability to support better than best effort does not mean that the application layer mechanism is expected to be activated. Further, we do not define the means by which better than best effort is or should be realized. Application-layer mechanisms that do not recognize ETS type labels are not subject to this requirement. “

More Related