Indication of Terminated Dialog draft-holmberg-sipping 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 Each UAS may establish an early dialog with the UAC –Early dialog establised by sending of 18x response

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

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.

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

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

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

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.

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?

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.

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

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

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

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.

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