1. SIP WG Open Issues IETF 50 Jonathan Rosenberg dynamicsoft

2. Subset vs. No Subset Rfc2543 inconsistent on whether SDP in response is subset of INVITE or not –Normative says SHOULD –Examples don’t, text in examples says MAY Minimal Subset –+ Helps reduce set of codecs you need to worry about –- Can’t represent sendonly codecs for a bidirectional stream (DTMF) What should spec say? –List receive codecs – more flexible

3. Cseq incrementing Rfc2543 says Cseq increments are “contiguous” Some list discussion may have said that it need not increment by 1. Incrementing by 1 important for ordering –Especially with all these new methods mid-call Clarification: –MUST increment Cseq by 1 for each transaction in a leg –If you receive a Cseq that is larger than previous by more than 100, reset Helps for crash recovery

4. TCP Connection Handling Spec says –If server closes connection before final response, = 500 –If client closes before final response, = CANCEL New CANCEL rules will cause proxy to reopen connection to send 487! Really bad for persistent connections between proxies Huge implementation nightmare Eliminates possibility of failover and high availability in TCP SIP networks Proposal: –Closing of TCP connections has no impact on SIP states Issue: are there clients or servers that use these features on purpose?

5. TCP Connection Issues Spec doesn’t say much about usage of persistent connections Recommend adding specific text about it Proposal –Connections indexed by [IP,port,transport] –Resolve URI, determine next hop tuple –Look for existing connection to tuple, and reuse Keep connections open until inactivity for some amount of time, configurable, recommended 30s Recommend persistent TCP when: –There are explicitly configured next-hops –Common in intra-domain cases When possible, has nice congestion control properties, message efficiencies

6. Response Failover Would like to survive failures of proxies mid- transaction Usage of received tag prevents this –Response always sent to server it came from Spec recommends domain name in sent-by to provide feature, but it doesn’t work! Proposal: –Send response to received param –If failure ICMP Timeout for invite non- 200 OK TCP connection gone –Use domain lookup processing on host in sent- by Only works for stateful proxies Bad if crashed proxy forks!

7. More tag issues From tags not mandatory –Last IETF, determined cases where this could result in problems –Need to make mandatory Spec says it SHOULD be unique within UA instance But, there are benefits to unique for each call leg –Ensures that Call Leg ID includes unique identifier contributed by both sides –Allows Call leg ID to be used for billing ID in half- trusted models Proposal: –Tags unique per call –MAY contain ID to associate them with UA instance –Best of both worlds

8. 409 and Multiple Contacts Spec says that registrar responds with 409 if UA tries to register Contact with an action different from current Proposal was made to remove that restriction Cons: –What is behavior? If there is no standardized behavior, will make things very confusing Pros: –Simpler for client? Proposal –No change to spec

9. Record Routing Still awaiting more comments on new text… Issue: what about unknown methods? New text says you can’t RR on them –If you don’t know what it is, you have no business RR Issue is proxies that are there for FW/NAT traversal –They don’t need to know method, but need to be on path Proposal: –Allow RR on any method –UA ignores RR if it arrives in a method its not supposed to

10. Meaning of re-INV w/o SDP Should be the same for INVITE and re-INVITE Like to maintain idempotency of requests Three (not two!) possibilities –No change –No media –You offer No change implies loss of idempotency No media violates m line matching models “You offer” seems to work –A INVITEs B w/o SDP –B returns SDP in response, generally same thing it is already using –A returns its answer is ACK Needed for latest 3pcc flows

11. Still an Issue: Early Media Results from interim meeting –UAC should be prepared to receive media on INVITE (clipping) -> not early media –UAS should be prepared to receive media on 200 OK –Move rest of early media to another draft Usage of 183/PRACK has problems –Bandwidth constraints –Turning of streams on hold –Overloading of PRACK/183 Desperately need an early media draft

12. One possible solution Reverse INVITE! When A calls B, and B wants to setup early media to A –B sends INVITE to A for new call –This call is associated to original Since its its own call, we can –Hang them up –Put them on hold SDP negotiations now limited to INV/200/ACK, no PRACK or others Drawback: –Weird –Not compatible with what people are doing now Lets see some drafts on alternate proposals..

13. Transfer out of Consultation Scenario on right –(1) A calls B –(2) A calls C –(3) A wants to transfer B to C sends REFER to B, with Refer-To of C Problem –How do we guarantee call from B reaches same instance of C A is talking to? A B C 1 2 3 REFER

14. Approaches Use Contact of A-C conversation in Refer to B –Contact may not be globally routable (ACD) –NAT Use From/To of A-C call with Accept-Contact –To/From may not be usable if C called A –Routing logic may change during call Proposal –Hard problem –Use hybrid approach, try Contact then try From/To with Accept- Contact –Other suggestions?

15. Request URI Parameters Whats allowed, whats not allowed, and whats recommended? Maddr and port and transport are a MUST if they exist in the URI and you don’t send request there Unknown URI params are allowed –Needed for getting state back Currently, header params not allowed –Makes sense; using this URL would cause those params to be put into actual header Same with method param

16. Reinvite Glare Reinvite glare = both sides reinvite at same time Can be confusing since session state depends on order of 200 OK and INVITE from single participant Current solution is 5xx w/ random Retry-After if you get re-INVITE while reinviting Retry-After has second granularity May take time to resolve

17. Reinvite Glare Proposal I –Meaning of Retry-After is choose a number from zero to this value –Changes existing semantics Proposal II –Include Cseq of last received INVITE in INVITEs I send –Allows recipient to detect problem and one side to back off Proposal III –Granularity not an issue –Probability sufficiently low to ignore Suggestion –Proposal III

18. Preloaded Route Headers Can you send an initial INVITE with Route headers? Issues –Where does Route headers come from Orthogonal –Route headers stripped out, so route not rebuilt! Solution –Proxies really SHOULD re-insert RR in each request, even when Route present –Needed here plus several other places –So, will only work with bis proxies

19. SRV randomization issues Stateless proxies can send retransmissions of same request to different next hops Spec now says that stateless proxies use hash of Call-ID as index to randomization algorithm Two issues –Consistent selection of server for a transaction also for stateful proxies –Algorithm may still fail if results of DNS query returned in different order or change in zone –Need to alphabetize?