SIP WG Open Issues Jonathan Rosenberg Meaning of

SIP WG Open Issues Jonathan Rosenberg

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

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

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 3 pcc + preconditions

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

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?

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 – – Don’t add KISS No demonstrated need Security issues unsolvable

Early Media • Many issues with early media – No way to modify once it starts, since re-INVITE while INVITE in progress is disallowed – Can’t easily get transferred while on hold – Can’t 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

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

Transfer out of Consultation • Scenario on right – (1) A calls B – (2) A calls C – (3) A wants to transfer B to C C 1 • 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? B 2 3 REFER A

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?

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 – That’s the pain of implementing/shipping products based on experimental – 00 drafts

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

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

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

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

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

Overlap • Current approach: – Each digit(s) are new INVITE with new To, RURI, same Call-ID, increasing C-Seq – Terminating GW sends 400 to old ones as new come – Terminating GW sends 183 w/ RR headers, so INVITE can have preloaded Route • Issues: – Multiple call legs is not clean and not standard – Pre-loaded routes • Alternate Proposal – Same call leg – Use INFO for extra digits – INFO will never be seen by vanilla UAS, since it wouldn’t be reached until all digits were present – INFO only sent if UAS indicates it can do it

Pros/Cons • INFO approach – Uses single call leg – Still compatible with normal UAS – Hides overlap from sip networks (sort of) – But, sip network never sees actual dialed number – No way to provide apps to PSTN users • Multiple Call Legs – Very ugly – Requires many nonstandard behaviors – But, allows sip network to see end to end addresses

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

Timestamp Header • Issue: Spec says to reflect timestamp header in response, but doesn’t say which response • Answer depends on purpose • For Retransmit timing – Want RTT between client and next stateful server – That means ONLY 100 response! • Other applications? • Solution: – Mandate in all responses, 100 to 600

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