SIP Extension Changes Jonathan Rosenberg dynamicsoft IETF 52

Caller Preferences Accept-Contact now has OR-OF-ANDS construct –Accept-Contact: *;language=“en&es,de” –Negation still applies to entire construct Its use is not terribly clear –Use, instead of | for backwards compatibility Some oddities –Accept-Contact and Contact share syntax definition, BUT Contact is restricted, but not through BNF Meaning of comma is “OR” for A-C and AND for Contact Code was updated and verified

Caller Preferences Proxy can compute an “implicit” Accept- Contact –Users register support for different media types –Incoming request has SDP for a particular type –Proxy computes A-C Proxy UA REGISTER REGISTER INV M=audio Implicit Accept-Contact: *;media=“audio/*”

Caller Preferences Clarified: only one instance of each param (I.e., only one media=“”) Align only=true syntax with others in LWS Clarified only=true usage Caller prefs need to be in ACK/CANCEL if they were in INVITE Caller prefs useful primarily for unrouted requests –Interaction with routing process specified Updated cancel feature to be consistent with bis-05 defaults Camel case function names in code

Changes to guidelines Alignment with draft-tsvarea-sipchange –This doc provides the technical details of the requirements there How sipping should decide if a problem is right for SIP How SIP authors should write protocols

Changes to sip-nat Registrar should use rport and received from bottom Via, not source –Allows for proxies between UA and registrar Have to place Translate in 200 OK to REGISTER –Otherwise, no way to know which address is the translated one When maddr is also present in via, it takes precedence –Rport and received are ignored Open Issues –Translate syntax cludgey –Can eliminate if we can solve the multi-proxy issue another way

Multi-Proxy Problem Alternate soln –Open TCP to server –Send OPTIONS w/ rport –Response Via has rport and received – got your address! –REGISTER using that address Problem –Need to get incoming calls through THAT proxy Client Proxy REGISTER INV

Early Media Discussion Do we want to solve this problem? –If yes, needs to get on some charter somewhere What are the requirements –Backwards compatible? –INVITE response reflects actual call status Important for services –Callee has to offer early media –Callee should only offer early media if caller supports –Caller can reject offer –Caller can respond to offer with new codecs/ports –Caller can hold early media –Caller can change ports/codecs for early media –In forking, multiple UAS can offer early media –UAC can accept/reject each early media stream –Smooth transition from early to final media Shouldn’t require port change, for example –Solving media clipping is a different problem –Soln not PSTN specific –Preserves O/A model in INV/200/ACK –Allow for indication of local alerting or in-band early media

Early Media Requirements –Can have separate early media stream from final stream OK to correlate and be different UAS –Allow for preconditions on early media –Backwards compatibility with proxies that do midcom –Simple (MAAP) –Should use response codes for final responses rather than inband media Others??

Solution Axes Do we use O/A How to send EM offer from UAS How to send EM answer from UAC O/A mapping for having UAS update EM O/A mapping for having UAC update EM