SIP ML Open Issues Jonathan Rosenberg dynamicsoft Transport

SIP ML Open Issues Jonathan Rosenberg dynamicsoft

Transport Params z SIP URL only allows z Alternative one transport y. Registrations can have more than one for z What if many are each transport supported? y. URLs in web pages z Suggestion on list was probably shouldn’t to define a have transport at all, rely on SRV transport”s” parameter with a list z Suggestion: y. No change to spec

OPTIONS and REGISTER Max. Forwards 0 z How should proxy handle if these have M-F: 0? z Suggested resolution: y. REGISTER is 483; don’t process registration y. OPTIONS MAY be 483; MAY include Supported header z Action Item y. Clarify in spec

Dave’s Error Information z Dave Oran suggested mechanism for allowing more info to be obtained on error responses z URL in response z Issue: Contact or new URL? z List Resolution y? ?

UDP Mandatory z Bis draft mandates UDP z Why? y. C->C not possible otherwise y. Converting proxies would need to record route y. Complex z Most implementations do it anyway z PINT folks complained z Proposal: y. UDP remains mandatory

Multiple Outstanding Requests z Can a UA have multiple requests to same call leg without responses yet? z Actually needed y. COMET y. PRACK z Probably useful other places z Proposal ymultiple outstanding requests allowed yfor INVITE, only most recent matters

DTMF z Later. . .

Images Embedded in SIP z Inclusion of images and other content useful within SIP y when content relates to signaling - I. e. , caller ID z Can be done by including bodies z How to handle indirect references? y Header y URI List in body z What is reason for content? y Caller ID y Progress tones/images z Solutions y Parameter of a single header x. Better extensibility y Separate parameters x. Avoids registration/namespace management of params

Tags in Reverse Re-INVITEs z A INVITES B (no tag in From), 200 OK has tag in To z B re-INVITEs A. To field has no tag. Should B insert tag? z Yes y. Proxies may do so not call stateful and won’t know it’s a re. INVITE y. Idempotency y. Handles crash and reboot of A z No y. Requires changing call leg index mid call z Proposal y. Go for yes z Another idea y. Make From tag mandatory in INVITE

State pushing through Route z Would like to allow z But are parameters of proxies to push state Route pushed into Route, get it back Request URI? later z Proposal z Problem: inserting y. No, URI parameters are only URI data into Recordparameters Route, doesn’t come y. Use State header back in Route z Route header popped into Request-URI

Loops in Reverse Spirals z INVITE from A to B spirals through P 1 y. P 1 record routes twice z re-INVITE from B to A y. Route header has user@host all the same yonly maddr different, same for P 1 z Result is loop at P 1! z Possible solutions y. Don’t do loop detection with Route y. Use new URI parameter to differentiate

ACK in Recovered Proxies z A sends INVITE to P 1, z Solution proxies to B y. P 1 is now stateless y. It should not send an z P 1 crashes and ACK at all recovers y. Previous hop will send z B sends 400 response y. P 1 proxies ACK to B to P 1 y. Works fine z Where does P 1 send z Action item: ACK? y. Normally to same address as request URI, but it forgot yclarify in spec

Case Sensitivity z Again… z Current decision yusername CS ydomain CI yall param names and vals CS y. URI comparison, default value matches value not present z Any questions, last chance is now. .

User portion in RURI of REGISTER z REGISTER does not allow user part in request URI z Should this restriction be removed? z Not clear what the application is z Proposal y. No change z Related issue y. Domain in RURI and To field will almost always need to be the same. y. Clarify in spec

Content in 606 and 488 z Does 606 and 488 (No media in common) contain SDP? y. Spec says nothing z If it does, what is formatting of such SDP? y. IP address, ports? y. Which codecs listed? Send? Receive? z Proposal y. SDP allowed y. Stream listed if that type supported y. Codec listed if that codec supported bidirectionally y. IP address 0. 0 y. Port 0

; in URIs z Tel URI allows semicolon z What happens when converting tel URL to SIP url? z Choices y URL encode y Allow ; z URL encoding might have already been done z Wish to avoid recursive URL encodings z Proposal y; allowed in user portion of SIP URI

Mobility z Lots of questions here z Too early to debate until requirements and architectures are more firm

Multiple SDP Sessions z SDP allows multiple sessions per message z SIP implicitly assumes there is just one session per SDP z Can you have more than one? z Megaco uses more than one to express complex alternatives z Example: y. Audio stream on either IPv 4 or IPv 6 address? z Proposal y. Do not allow y. More complex things will require SDPng

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

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

Quotes in WWW-Authenticate z BNF and examples for params in WWWAuthenticate inconsistent in http z Do we use quotes or not? z Proposal: y. Quotes