1. SIP WG Open Issues Jonathan Rosenberg

2. Record-Routing Problem: spec omits anything about Routing in reverse direction Lots and lots and lots of discussion on list Source of unending confusion to implementors Meeting at bakeoff among: –J. Lennox, N. Deason, R. Sparks, J. Rosenberg, B. Biggs, B. Engelhom –yielded consensus!!!

3. Proposal Proxies can only use SIP URL in RR MAY insert any SIP URL they like, so long as it routes back to that proxy SHOULD insert a URL that, based on configuration/logic in server, routes to correct user –Open on how to do this UAS reflects RR, including RR-params, in 200 OK UAS builds route by taking all URLs, appending Contact else From UAC builds route by reverseing RR URLs, appending Contact

4. Proposal Proxy MAY modify RR URL in response –Simple procedure to find your URL by pushing/popping tags will be specified No transport param allowed in RR URL Preferences for UDP/TCP/TLS obtained ala SRV No special handling of rfc2543 only clients that dont insert Contact –Few of them –Works more or less anyway

5. Meaning of Call-ID Issue: what is the meaning of receiving an INVITE with a Call-ID matching an existing call, but different From? Possibilities –Additional party for an existing call –Replaces existing call (transfer types of function) –Nothing – new call as if Call-ID where different

6. Meaning of Call-ID Problems with new member semantic –Use of call-id as conference ID problematic for two party calls that need to merge to multiparty –Overloading of semantics Proposal –KISS –Call-ID has no conferencing semantics –Define formal ways to define (1) a conference and (2) replace call, if needed

7. Tag issues How is tag computed? –Unique within end system? Unique in each call? Depends on usages: –(1) Reject incoming requests, like unRouted BYE, that are not for UAS since UAS rejected call previously –(2) Differentiate multiple 200 OK responses to INVITE –(3) Identify a new call as for a UAS as one that is a re-INVITE for an old call after crash/restart

8. Solutions All three can be solved if tag is unique within UA instance, if that UA wishes to survive crash and reboots, else unique across calls BUT, there is a problem when a user calls themselves –Same tag in To/From, same To/From URI, cant tell for which leg an incoming call is for Proposal: –If you dont care about recovery from crash/reboot, its unique within a call –If you do care, you must Have two tags, each one a function of the UA (port + machine name) Always insert one into To, other into From Incoming calls with new Call-ID, but either of my tags, are for old calls

9. But More Problems A calls B, no tag in From. B answers, tag in To. A crashes. B sends re-INVITE. Now there is a tag in the From (the one B put in To). A gets re-INVITE. No tag in To field. Thinks its new call, adds tag in To field! B confused, since response now has a tag From: a To: b From: a To: b;tag=1 INV 200 From:b;tag=1 To: a INV From:b;tag=1 To:a;tag=2 200

10. Tag headaches continue Solutions –Mandatory From tags Completely solves What about clients that dont do it? –Allow tags to change Yucky to implement, multiple keys needed Most robust –Disallow change Mandatory tags + unlikelihood = who cares General issue: –If From didnt have tag originally, can it be updated later? –If request is answered by a stateless device (I.e., proxy) may happen!

11. Tag Migraines Now What about receiving BYE after crash and reboot? –Call-ID new, tag is one used by UA Should it send 200 OK or 481? 200 OK probably better General solution: –If you get a request with new Call-ID, old tag, basically use it to create a call and then execute message –Does that work?

12. SDP Semantics What exactly is SDP exchange procedure? –Can you have SDP in INV/200 and ACK? –If no SDP in INV, can you have SDP in 183 then PRACK? –Can you send additional 183, each with new SDP? How may it differ? Need to define a general process for SDP exchange SDP in PRACK for 3pcc + preconditions

13. Meaning of re-INV w/o SDP Should be the same for INVITE and re- INVITE Like to maintain idempotency of requests Two possibilities –No change –No media No change implies loss of idempotency No media makes more sense Is it better to have no SDP, or SDP with no m lines? –No SDP = other side should offer –SDP with no m lines, no media, can only add in re- INVITE

14. mid-Call Redirects Primary issue is handling of Route headers and proxy behavior UAC behavior: –Can abandon route set completely –Can use old Route set, and add Contact to end –Can use old Route set, replace last entry with new Contact Problems if new Contact is not UAS –Request may be proxied after last route entry –Request can then collect RRs –200 OK has new RRs –Cant update route set at UAC! Two solutions –Abandon route set –Mandate that mid-call redirects are to UAS only –Either way, recursion in proxies is bad

15. Pros/Cons Abandoning Route set –Allows route set to be updated –But, proxies on original path may be confused Redirect to UAS only –Hard to enforce, otherwise ideal –Argues for replacing bottom Route entry with new Contact Usage scenarios? –MGC about to come down for maintenance Existing call state transferred to standby Incoming re-INVITEs/ BYEs redirect to standby Realistic? Can be done at lower layers

16. IPv6 in SIP IPv6 in URLs not a problem –RFC2732 Usage of IPv6 addresses problematic in –Via –Warning –Extension params Defined as tokens –But v6 addresses can have :, which is a separator Solutions –Quote all v6 addresses Doesnt work for warning, via –Convert : to – –Redefine BNF for Warning, Via, extension params as token | host May break really picky parsers? Proposal: third approach

17. Response Authorization Specification allows for response authentication –Challenge placed in WWW-Authenticate in request –Response placed in Authorization in response Not implemented? Not clear there arent security issues No easy way to handle two pass proxy to UAS Authorization Inconsistent with rfc2617 Authorization-Info Proposal: –Deprecate –Allow Authorization-Info –Use PGP-MIME, S/MIME for PKI stuff

18. Overlapping Transactions Can you initiate a new transaction while one is in progress? What does it mean? Needed for a few cases: –PRACK for provisional responses –COMET for qos assured –INFO to send ISUP before call completes? Proposal: –Allow overlapping transactions under specific conditions –Final response for new transaction not dependent on final response of previous –Transactions do not affect state of each other –Can only do them once tags/route obtained from provisional response Too general? Too hard to use concretely?

19. Multiple From Some folks want to allow multiple addresses to identify sender –Telephone number, email like SIP URL Not supported in current SIP spec Network authentication of addresses was desired –Cross-domain signing issues Proposal was made to add Sender header, or equivalent, listing extra addresses My proposal –Dont add –KISS –No demonstrated need –Security issues unsolvable

20. Early Media Many issues with early media –No way to modify once it starts, since re-INVITE while INVITE in progress is disallowed –Cant easily get transferred while on hold –Cant put early media on hold –Difficult to reconcile with forking –Early media may not match code it comes in (180 + fast busy tone) –Requires PRACK –Eliminates possibility of sequential searches But, some kind of indication critical for ISUP mappings Two proposals –Live with it, widely used already –Deprecate, define separate billing related message to signal start of billing

21. Related: Media handling Should UAC be prepared to receive media right after sending INVITE? –If yes, why 183 needed? –RTCP Port –Indicate sendonly/recvonly Should UAC be prepared to receive media after 183 or 200? If 183 comes with SDP, is that always for reverse media only? –Can it contain SDP and establish bidirectional media? Security implications –Receive media without message in other direction = big hole for attackers –183 could contain info for IPSec or TLS connection establishment

22. 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

23. 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?

24. REFER Timeouts REFER transaction must complete in 32 s INVITE it triggers may not complete in 32 s REFER may time out Basic problem is that non-INVITE is meant for rapid responses Solutions –REFER completes immediately, REFERDONE or otherwise sent when request finishes –Punt –Respond to REFER within 16s if no final response comes, using 202

25. BYE/Also Expired draft Replaced by REFER Some people still have it implemented Want it put into bis draft for backwards compatibility IMHO, BAD –Interop/maintenance nightmare –Thats the pain of implementing/shipping products based on experimental –00 drafts

26. 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 dont 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

27. 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

28. 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

29. 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

30. 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?

31. Message/Header lengths 1500 message limit exceeded frequently Many implementations limit header sizes or parameters What should spec say about these things, if anything? Proposal: –SHOULD allow any message up to 64k –SHOULD allow any number of each header –SHOULD allow headers of any size (not beyond message size limit)

32. THANKS! TO: Tom Taylor Bert Culpepper Ben Campbell Igor Slepchin Balaji Narayanan