1 / 7

IETF 80 Prague DISPATCH WG

IETF 80 Prague DISPATCH WG. draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske: r.jesske@telekom.de Laura Liess: Laura.Liess@telekom.de. IETF 80 Prague. draft-jesske-dispatch-update3326-reason-responses-01. Roland Jesske. Past Approach.

vielka-cline
Download Presentation

IETF 80 Prague DISPATCH WG

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. IETF 80 PragueDISPATCH WG draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske: r.jesske@telekom.de Laura Liess: Laura.Liess@telekom.de IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  2. Past Approach • After IETF 76 a split of requirements and procedures was done • draft-jesske-dispatch-reason-in-responses-03.txt • draft-jesske-dispatch-req-reason-in-responses-02.txt • Drafts describe to use the Reason Header in SIP responses to transport Q.850 ISUP Causes. IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  3. Post IETF 76 discussion • That encapsulation needs an implementation of SIP-T or at least the syntax for the MIME and the Q.850 cause while the Reason header is already defined within RFC3326. • That translation regarding RFC3398 can not guarantee a proper mapping that results in proper announcements which are needed in a hybrid SIP/POTS/PSTN network. • Also in PSTN-SIP-PSTN scenarios (not using SIP-T) will end up in wrong Q.850 Cause Codes at the PSTN end IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  4. Conclusions Working group mailing list discussion as to whether the individual draft describing the procedures of the SIP encapsulating the Q.850 response values in Reason header was the objective or whether the primary requirement was for the basic protocol support for Reason header in responses. Working group conclusion on email list was that an UPDATE to RFC3326 fulfills the requirements - addresses a gap/inconsistencies in RFC3326 draft-jesske-dispatch-update3326-reason-responses-01 was submitted. After discussion comments have been resolved - Version 02 is in the queue. IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  5. Original text RFC 3326: The Reason header field MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header. IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  6. Updated Text for RFC3326 The Reason header field only containing a Q.850 Cause Code MAY appear in any request within a dialog, in any CANCEL request . The appearance of the Reason header field only containing a Q.850 Cause Code is applicable to final responses 3xx, 4xx, 5xx and 6xx and 18x and 199 [I-D.ietf-sipcore-199].The Reason header field containing any other reason value MAY appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

  7. Questions / CommentsNext Steps IETF 80 Prague draft-jesske-dispatch-update3326-reason-responses-01 Roland Jesske

More Related