1 / 15

Indication of Terminated Dialog

Indication of Terminated Dialog. draft-holmberg-sipping-199-02.txt Christer Holmberg NomadicLab Ericsson. INTRODUCTION. Due to forking, an initial INVITE request may be forwarded towards multiple UAS entities Forking performed by forking proxy

ferrol
Télécharger la présentation

Indication of Terminated Dialog

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. Indication of Terminated Dialog draft-holmberg-sipping-199-02.txt Christer Holmberg NomadicLab Ericsson

  2. INTRODUCTION • Due to forking, an initial INVITE request may be forwarded towards multiple UAS entities • Forking performed by forking proxy • Each UAS may establish an early dialog with the UAC • Early dialog establised by sending of 18x response

  3. INTRODUCTION • If an UAS sends a non-200 final response, it is not directly forwarded towards the UAC by the forking proxy • The forking proxy ”collects” final responses, and then forwards a single, ”best” final response

  4. RESULT • If the UAS sending the non-200 final response has established an early dialog with the UAC, the UAC will not directly be informed about the termination of the dialog, since the forking proxy does not forward the final response towards the UAC.

  5. EXAMPLE (parallel) UAC Proxy UAS_1 UAS_2 INVITE INVITE INVITE 18x To tag = UAS_1 18x To tag = UAS_1 18x To tag = UAS_2 18x To tag = UAS_2 4xx To tag = UAS_1 4xx not forwared towards UAC Time during which the UAC still thinks the early dialog with UAS_1 is active 200 To tag = UAS_2 200 To tag = UAS_2 Early dialog with UAS_1 terminated

  6. EXAMPLE (serial) UAC Proxy UAS_1 UAS_2 INVITE INVITE 18x To tag = UAS_1 18x To tag = UAS_1 4xx To tag = UAS_1 4xx not forwared towards UAC INVITE 18x To tag = UAS_2 18x To tag = UAS_2 Time during which the UAC still thinks the early dialog with UAS_1 is active. 200 To tag = UAS_2 200 To tag = UAS_2 Early dialog with UAS_1 terminated

  7. ISSUES • Since the UAC thinks that the terminated early dialog is still active, it may: • Keep resources reserved for the early dialog • Codec, bandwidth, radio... • Continue procedures associated with the early dialog • ICE, keep-alive, media plane security negotiation, pre-conditions, resource reservation • Reject/restrict additional early dialogs • Try to send SIP requests on the early dialog

  8. Early media • It can be useful for the UAC to know that media associated with a specific early media will for sure no longer be received • Codecs reserved only for the terminated dialog can be released • UAC may ”switch” to another media stream, associated with another early dialog • The purpose is NOT to solve generic early media problems • The purpose is NOT to define a generic way to associate media streams with early dialogs.

  9. Information to UAC • If the UAS includes information, which may be useful to the UAC, in the non-200 response, it may not reach the UAC. • The proxy will only forward one non-200 response • Example: Sending of original error response to the UAC • Example: Could this be useful for draft-polk-sip-rph-in-responses-00?

  10. Time • In scenarios with e.g. media announcements, and/or serial forking, it may take a relatively long time (minutes) before a final response is fowarded towards the UAC. • The time may not always be the main issue, but the fact that the UAC can handle a limited number of early dialogs with resources and/or procedures associated.

  11. Relationship with HERFP(Heterogeneous Error Response Forking Problem )draft-mahy-sipping-herfp-fix-01.txt • HERFP draft provides a mechanism for a UAC to, in a forking environment, be informed about the final response of multiple forked INVITEs, so that it in some cases can take certain actions and send a new INVITE to a specific UAS, which may not be rejected • 199 simply informs the UAC that a dialog has been terminated • Whether we would encapsulate the original final response can be discussed, but is not needed to fulfil the requirement itself

  12. Relationship with HERFP(Heterogeneous Error Response Forking Problem )draft-mahy-sipping-herfp-fix-01.txt • 199 does not assume the UAC to send a new INVITE once it has been informed about the terminated dialog • Does not need to associate a ”new” INVITE with the ongoing INVITE transaction. • Proxy does not need to provide a URI pointing towards the UAS from where the non-2xx final response was received • No need to define a new DECLINE method • Applicable to all non-2xx responses • Only sent if an early dialog has been created

  13. IMPLEMENTATION • New 199 provisional response code • Who sends 199? • The forking proxy? • The UAS? • Can 199 be used with PRACK? • Etc etc etc • NOT TO BE DISCUSSED HERE AND NOW – WE ONLY FOCUS ON WHETHER A MECHANISM COULD BE USEFUL

  14. PROPOSAL • Define a mechanism to inform the UAC about a terminated dialog as soon as the dialog termination takes place. • Proposed requirement: “It MUST be possible to inform the UAC, before a final response is sent by the proxy, that a specific early dialog has been terminated.” NOTE: Proposed requirement does not talk about WHO (UAS, forking proxy etc) informs the UAC about the terminated early dialog.

  15. QUESTION • Does the SIPPING WG think this is a valid requirement, and a useful thing to work on? • If so, the detailed protocol work will be done in the SIP WG

More Related