IETF 91 DISPATCH draft-jesske-dispatch-forking- answer-correlation-02 Roland Jesske

Problemstatement SHOULD  RFC3261 SIP defines Forking as an option  handling of responses should apply properly REALITY  There are network elements/UE‘s that does not handle multiples early answers to forked INVITES properly or have restrictions  Mainly network elements interworking with PSTN  Interconnection agreements may allow only one early dialog because of load issues 2

RFC’s influencing the handling of Forking RFC3261 Description of forking and correct response handling RFC3841 Caller Preferences for the SIP  no fork directive RFC5393 Addressing an Amplification Vulnerability in SIP Forking Proxies  Max-Breadth header to avoid to many forked Requests RFC6228 SIP Response Code for Indication of Terminated Dialog  199 response helps to close early dialogs. RFC3326 The Reason Header Field for SIP  "Heterogeneous Error Response Forking Problem", or HERFP (encapsulation of Response) RFC3262 Reliability of provisional responses  multiples responses needs correct handling with PRACK. (Forking not mentioned in RFC) RFC3312 Integration of Resource Management and SIP  multiple resource reservation needed. (Forking not mentioned in RFC) … 3

Requirements for B2BUA providing Forking correlation Why: improve end to end interoperability with devices (UA, networks, and network components) which do not support multiples responses based on a forked request Requirement on B2BUA: correlation/multiplex of multiples early dialogs to a single dialog source based correlation (does originating entity, network supports forking?) allow manipulation of SIP to avoid or reduce Forking (e.g. no-fork, Max-Breadth) based on SIP-network interconnection agreement. 4

Use Cases to be considered in the draft Normal Forking Forking (Multiples provisional responses without SDP) Forking (INVITE 100rel supported is set and in 18x a SDP with 100rel required is sent back) Forking (Forking use case with provisional responses with SDP using 100rel and preconditions) Multiples early dialogs due to call forwarding Announcements within the path – Avoidance of announcements – correct correlation of announcements Avoidance of Forking with no-fork and other mechanisms Other possibilities 5

Forking Scenarios 6

Forking Scenarios using Caller Preferences 7

Backup

Current discussion of issues on the DISPATCH list General to label all messages in case they contain SDP – redraw figures Section 4.1 – Figure 1 (normal Forking) to easy show more complex case – Question: what happens in case when UE relates to the last received information of last 18x 9

Current discussion of issues on the DISPATCH list Section 4.2 Role of responses 180, 181, 182, 183 due to the scenarios. – Forwarding of call and 181 back – alert-info header Section 4.3 Use of 100rel when SDP answer of UA‘s are different compared to the offer. (e.g. Codec, PT) 10

Thank You