1. SIP Working Group Stuff Jonathan Rosenberg dynamicsoft

2. Caller Preferences Changes Rewrite for dependence on rfc2533 –RFC2533 = A Syntax for Media Feature Sets –Specifies matching of preferences and capabilities –Initial application was HTTP Content Negotiation Syntax is unchanged –Spec describes how to map to rfc2533 –Then points to 2533 for performing matching operation Optimizations are possible! –2533 algorithm is complex –Caller prefs limits the types of expressions (conjunctive form on orthogonal tags) –More efficient algorithms (like the one in –04) can be used

3. Actual Semantic Changes “type” feature tag now only for complete types –“media” tag for top level types – audio, video, message –For alignment with existing tags Added automata tag –Boolean –For robots, voicemail servers Added “events” tag –For RFC 3265 event types –Presence, winfo, etc. Some changes in priority matching –Can register multiple priorities: ;priority=“urgent,emergenc y” –However, multiple is redundant – lowest will be used –Can also ask for explicit priorities in Accept-Contact

4. More Changes Q-value has to be the last parameter amongst the Accept/Reject-Contact header values –There is ONE construction for feature sets in all headers New: Explicit preferences –Previously, server handled methods, priority differently –Constructed caller preference from request method, Priority header –Now, caller can explicitly state preference: A-Con: *;methods=“INVITE,REFE R” –Allows you to ask for a UA with specific capabilities –Implicit still done, but explicit overrides implicit

5. More Changes URI matching still allowed, but restricted –User and host –Just host –All URI params ignored Unification of allowed feature sets between Contact and Accept- Contact Eliminate the & construct –Based on RFC 2533 definition of feature sets, it doesn’t make sense as defined

6. Open Issue #1: Overlap Overlap in Function when used in INVITE Contact –Intent was to allow UA to describe itself –Several parameters overlap with SIP headers –Methods and Allow –Events and Allow-Events –Types,media and Accept –Languages and Accept- Language What do we do about it? –1. Allow both, define one as taking priority –2. Forbid caller prefs from using params also present through headers –3. Disallow use of caller prefs in INVITE/200 –Proposal: [1], with headers taking priority

7. Open Issue #2: Other extensions Caller prefs has no way to indicate which Contact params are “its” as opposed to another extension. Example: Contact: sip:u@d;extension- param=3;mobility=fixed Is “extension-param” for caller prefs or not? –May not matter! –It is present in both Accept- Contact and Contact, then it is Related Issue: Can we apply caller prefs to unknown parmeters? –Would like to –But what are the matching rules? –Not clear from rfc 2533 if its allowed

8. SIP-NAT Previous draft covered two problems –Receiving responses through NAT (rport) –Receiving requests through NAT (Translate header in REGISTER) Translate header had issues –For UDP, required very frequent re- registers –Introduced some NAT- specific things (nat- type parameter) –Was a big hack –Repeated what STUN was doing

9. New Scope Proposed new scope: –Make sure SIP can work with STUN, SPAN, TURN –No more, no less Result of the scope: only rport parameter remains –Without this, STUN wouldn’t work Ultimately, TCP is the right answer In that case, only problem is registrations –Handle that as a connection reuse problem –Applies to proxy-proxy connections as well