SIP WG Open Issues IETF 50

1. SIP WG Open IssuesIETF 50 Jonathan Rosenberg dynamicsoft

2. 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 Subset vs. No Subset

3. 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 Cseq incrementing

4. 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? TCP Connection Handling

5. 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 TCP Connection Issues

6. 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! Response Failover

7. 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 More tag issues

8. 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 409 and Multiple Contacts

9. 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 Record Routing

10. 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 Meaning of re-INV w/o SDP

11. 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 Still an Issue: Early Media

12. 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.. One possible solution

13. 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? Transfer out of Consultation C B 2 1 3 REFER A

14. 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? Approaches

15. 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 Request URI Parameters

16. 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 Reinvite Glare

17. 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 Reinvite Glare

18. 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 Preloaded Route Headers

19. 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? SRV randomization issues