March 20th, 2001 SIP WG meeting 50th IETF SIP WG meeting Overlap signalling handling

March 20th, 2001 SIP WG meeting 50th IETF Outline Background on discussions so far En bloc INFO Multiple INVITEs Proposed solution and its implications

March 20th, 2001 SIP WG meeting 50th IETF Background of discussions so far Already too much discussion in the mailing list problem: 80% important technical work 20% time General feeling: We MUST resolve this and move on!! Three proposals: The WG picks up one (in this meeting) En bloc INFO Multiple INVITEs

March 20th, 2001 SIP WG meeting 50th IETF En bloc proposal Let’s forget about overlap signalling. Let gateways deal with “overlap” to “en bloc” conversion Minimum amount of digits received: Start T10 Arrival of new digit(s) refreshes T10 T10 expires (no more digits accepted): INVITE sent Already presented and rejected (47th IETF in Adelaide) Reason: Introduces an unacceptable establishment delay

March 20th, 2001 SIP WG meeting 50th IETF En bloc proposal: Pros and cons Pros SIP network untouched Cons En bloc calls are affected by establishment delay A particular gateway that might eventually receive SAMs always implements T10 Requirements on establishment time Unacceptable to wait for T10 to expire once the last digit has arrived If we decide to go for this proposal, some folks will implement their own solution anyway

March 20th, 2001 SIP WG meeting 50th IETF INFO proposal Everything we want from SIP is to find the egrees gateway and then become a transport protocol INVITE upon reception of IAM INFOs carry SAMs

March 20th, 2001 SIP WG meeting 50th IETF INFO proposal: Pros and cons Pros Reduces the number of SIP messages exchanged Cons Breaks application servers no SIP services If we do not want SIP services, why do we want to use SIP-T? Does not work with vanilla SIP UAs It is just for gateways If we do not want to interwork with vanilla SIP UAs, why do we want to use SIP-T? INFOs do not carry complete state (what if we get 484 for the INVITE?)

March 20th, 2001 SIP WG meeting 50th IETF Multiple INVITEs Let INVITEs carry complete state Let us send a well-formed INVITE every time more digits arrive (with an updated To header)

March 20th, 2001 SIP WG meeting 50th IETF Multiple INVITEs proposal: Pros and cons Pros Works with application servers Works with vanilla SIP UAs INVITEs carry full-state (robustness, no synchronization problems) WG has been working on this solution over a year Well-known issues Cons Many messages exchanged Generality over efficiency

March 20th, 2001 SIP WG meeting 50th IETF Proposed solution So far, the multiple INVITEs proposal seems to be the “least bad” of all three… But what about the technical issue we had with load balancers?

March 20th, 2001 SIP WG meeting 50th IETF Issue to resolve Proxies performing some kind of load balancing might route different INVITEs to different egrees gateways We get two IAMs rather than one IAM and one SAM

March 20th, 2001 SIP WG meeting 50th IETF Solution This is not an overlap related problem. It is a general issue that has a general solution Many SIP UAs send BYE rather than CANCEL Section RFC2543bis: “ A UAC MAY send a BYE or CANCEL request after the seventh retransmission. It is RECOMMENDED to send both. (This avoids call establishment in case the network path loses packets asymmetrically.)” Might be useful that MESSAGEs follow the same path Routing of requests within a session before a Route can be built

March 20th, 2001 SIP WG meeting 50th IETF SRV records and load balancing Text added in September to RFC2543bis (section 1.4.2): Add SHOULD within a call. Remove transaction-identifiers Subsequent requests almost always are sent to the same place Introducing variables in the hash besides the Call-Id does not achieve better randomization Within a transaction, a stateless proxy MUST always select the same destination within the set of hosts with the same priority. This can be accomplished, for example, by using the modulo N of a hash of the Call-ID value or some other combination of transaction-identifying headers as the uniform random number described in the weighting algorithm of RFC Here, N is the sum of weights within the priority class.

March 20th, 2001 SIP WG meeting 50th IETF SRV records and load balancing Suggested text: Within a transaction, a stateless proxy MUST always select the same destination within the set of hosts with the same priority. Within a call, a stateless proxy SHOULD always select the same destination within the set of hosts with the same priority. This can be accomplished, for example, by ordering the hosts in alphabetical order and then using the modulo N of a hash of the Call-ID value or some other combination of transaction-identifying headers as the uniform random number described in the weighting algorithm of RFC Here, N is the sum of weights within the priority class. Text added Text removed

March 20th, 2001 SIP WG meeting 50th IETF Privacy in ISUP-SIP mapping ISUP CgPN presentation indicator mapping to SIP –Proposal: use a dummy From field –Is information about gateways themselves (IP address, etc) similarly in need of privacy protection? How much would this reveal about the user? Is this the same issue that is addressed in draft- ietf-sip-privacy-01 (with Remote-Party-ID and Anonymity headers)? –GW-GW sessions could use encapsulated ISUP (do GWs ever need to hide info from one another?) –Should ISUP-SIP mapping assume a network containing trusted intermediary proxies? What does sip-privacy-01 prescribe if network isn’t trusted? Dummy From?