SIP Working Group Stuff

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 prioritiespriorityurgen
  t,emergency
• 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
  preferenceA-Con methodsINVITE,REFER
• 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
  doesnt 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.
• ExampleContact sipu_at_dextension-param3mobili
  tyfixed

• 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 wouldnt 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