SIP Working Group Stuff Jonathan Rosenberg dynamicsoft Caller

SIP Working Group Stuff Jonathan Rosenberg dynamicsoft

Caller Preferences Changes • Rewrite for dependence on rfc 2533 – RFC 2533 = 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 rfc 2533 – 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

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

More Changes • New: Explicit preferences • Q-value has to be the – Previously, server handled last parameter amongst methods, priority differently the Accept/Reject– Constructed caller preference from request Contact header values method, Priority header – There is ONE construction for feature sets in all headers – 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

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

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

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; extensionparam=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

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 NATspecific things (nattype parameter) – Was a big hack – Repeated what STUN was doing

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