SIP questions
Henning Schulzrinne
Columbia University IRT Lab
Siemens
Munich -- January 2003
SIP bugs



http://www.sipwg.org/sipwg/
54 bugs listed
likely lead to either an addendum or re-issue
at Proposed


Draft Standard requires promotion of DNS SRV,
NAPTR, TLS, …  unlikely anytime soon
currently, in bug-gathering phase, since none
are critical


a few require discussion
very few seem to have backwards-compatibility
issues
SIP bugs - editorial
585
Various text-formatting problems
592
ToC in the pdfs is missing references
section
645
srvr production rule contains extra "@"
654
Text on CSeq ordering missing equality
674
"2xx class" terminology still occurs in
places
608
Definition of "optional" in table 2/3
inconsistent with usage
643
Offer and answer rules repetitive
644
Proxy or UAS vs. UAS or proxy
line breaks, periods,
spaces, …
need “optional to
insert, mandatory to
process” designation
SIP bugs – editorial
651
21.4.1 example about missing call-id
should be changed
657
Missing branch parameters in examples in
Section 18.2.1
660
Table 2 entry for Authorization in a
CANCEL should be a N/A
666
Clarify use of expires=xxx with
terminated
681
B2BUA definition – keep, remove or
change?
684
Explicit language banning response to ACK
has been lost
685
Example Server header field confusing
SIP bugs - security
646
Explain TLS mode more clearly
We expect proxy servers and registrars to
authenticate themselves via cert, while clients will
typically not have one, but use the secure channel to
improve the security of Digest, would behelpful.
619
No response code defined for
unverifiable certs
Should indicate nature of problem,
to allow fall-back
652
Clarify MUST include certificate
statement
either CMS or content-indirection
631
Values of nonce-count, method Unclear what should be placed in
param in ACK digests
ACK
679
S/MIME for registrars
Assumes TLS (bad), but doesn't
work for proxied REGISTER;
SHOULD or MUST?
SIP bugs – error behavior
40
Meaning of 3xx response to re-INVITE
653
Why do we return 500 for CSeq out of
order?
305
What does the UAS restriction on 305
mean?
663
Handling failure of proxy after 100, but
before proxying
668
"423 Subscription too brief" doesn't match
RFC 3261
667
Reason code for unsubscription/poll not
clearly spelled out
3xx in re-INVITE not
allowed
SIP bugs – error behavior
673
INVITE 481 response effect
clarification
683
Update CSeq on failed
request?
updating the CSeq on failed requests
might be used as a DOS attack if
lower-CSeq requests are rejected
687
Handling transactions with
equal sequence numbers
Doesn't say what UAS should do if a
request has a sequence number equal
to the previous one.
SIP bugs – protocol format issues
656
Deprecate comments in RetryAfter
accidentally remain in Retry-After;
should not be used
583
3xx to INVITE should have at
least one Contact
Text can be interpreted as
allowing empty contact list (or
disallow more than one).
650
Allow in REGISTER
SIP bugs – URI & transport
598
100 trying needed for TCP?
658
First well known rule can be
from maddr
675
Sending requests to nonSIP URI
678
Support for UTF-8 in the
SIP URI
100 not really needed for TCP;
CANCEL can't be sent before that 
allow for TCP.
Are user names UTF-8? (Yes!) Who
performs canonicalization for
comparisons – UAC or proxy?
SIP bugs – tags and branches
648
Branch hash calculation needs explicit
comment for loop
649
Clarify randomness in tags
659
Stateless proxy branch computation
invariant across CANCEL
661
Case insensitivity of branch ID
665
PRACK matching still uses CSeq, should
ideally use branch
680
Stateless proxies and branch IDs
SIP bugs – Record-Route
664
Double record-routing
Record both inbound and outbound
interface for multihomed proxies.
SIP bugs – dynamic behavior
610
Response failover and statelessness
671
Dialog state machine needs clarification
682
Expires header or param in REGISTER
responses
686
Overlapping transactions in a dialog,
revisited
SIP bugs – early dialogs and
media
611
Creation of early dialogs at UAC is a MAY
647
Inconsistency in when to stop listening for
media on old
676
What does responding with hold mean?
SIP bugs – events
669
Clarify: SUBSCRIBE for a duration might
be answered with
671
Clarify timeout-based removal of
subscriptions
672
Mandate expires= in NOTIFY
677
SUBSCRIBE response matching text in
error
Session model for instant
messaging

No recent public discussion, but apparently design team at work


Primary motivation:





bypass SIP proxies
reliable channel  avoid concerns about message size
more efficient encryption and signing
integration into multimedia sessions
Open issues:


moving towards SDP specific to CPIM messages, instead of
comedia
proxies ever needed or is B2BUA good enough here?
Proposals:



SIP-lite 
BEEP 
CPIM (draft-campbell-simple-im-sessions, draft-campbell-simplecpimmsg-sessions)
CPIM session model



draft-ietf-impp-cpim-msgfmt-07
Some annoying formatting differences to SIP,
but close
SDP negotiation uses comedia, but doesn't fit
well (port reuse, security)  in transition
c=IN IP4 alice.example.com
m=message 7394 cpim/tcp text/plain
a=direction:both
a=uri:im:2s93i9@alice.example.com
c=IN IP4 bob.example.com
m=message 8493 cpim/tcp text/plain text/html
a=direction:active
a=uri:im:849ro3@bob.example.com
CPIM example
From: MR SANDERS <im:piglet@100akerwood.com>
To: Depressed Donkey <im:eeyore@100akerwood.com>
DateTime: 2000-12-13T13:40:00-08:00
Subject: the weather will be fine today
Subject:;lang=fr beau temps prevu pour aujourd'hui
NS: MyFeatures <mid:MessageFeatures@id.foo.com>
Require: MyFeatures.VitalMessageOption
MyFeatures.VitalMessageOption: Confirmation-requested
MyFeatures.WackyMessageOption: Use-silly-font
Content-type: text/xml; charset=utf-8
Content-ID: <1234567890@foo.com>
<body>
Here is the text of my message.
</body>
header
encapsulated
MIME content
Security


Not much movement – considered first-stage
complete
Work on Authenticated Identity Body (AIB)



Some murmurings on reviving Basic
authentication




signed subset of SIP
not clear how proxies can do the signing
avoids storage of valuable key on server
What about untrusted end systems?
Proposal for public key retrieval via OPTIONS
Single sign-on: SAML and SIP?
Transport protocols


Clear movement towards TCP (and TLS)
No indications that SCTP is widely
implemented in SIP proxies


not much performance benefit in practice
(see Camarillo/Schulzrinne paper on
performance comparison)
UDP not likely to disappear from spec
(gratuitous incompatibility)
Stray responses




Responses without proxy state are routed
statelessly to UAC
Problem: 408 (timeout) for unreachable UAS
can trigger an avalanche of responses
Proposal: suppress error responses or at least
408
Evaluation: 4xx needed by caller



avoid special cases
usually, only last proxy needs short (user-oriented)
timeout  let it clean up the chain
however, not clear if proxy knows its position in
chain
What is CASP?

Generic signaling service


establishes state along path of data
one sender, typically one receiver




can be used for QoS per-flow or per-class reservation
anything that establishes temporary state roughly along a data
path
but not restricted to QoS:




can be multiple receivers  multicast
node and link discovery (link speed and properties, packet loss)
deposit active network code
control firewalls and NATs
avoid restricting users of protocol (and religious arguments):


sender vs. receiver orientation
more or less closely tied to data path


router-by-router (on-path)
network (AS) path (off-path)
CASP properties

Network friendly



mobility friendly



any reliable protocol
initially, TCP and SCTP
policy neutral


no particular AAA policy or
protocol
interaction with COPS,
DIAMETER needs work
soft state





data format
negotiation
Topology hiding


per-node time-out
explicit removal
extensible

handles path changes
transport neutral


congestion-controlled
re-use of state across
applications

not recommended, but
possible
Light weight



implementation complexity
security associations (reuse)
may not need kernel
implementation
CASP network model – onpath
selective ("vegetarian")
CASP chain
QoS
QoS
QoS
midcom
omnivorous


CASP nodes form CASP chain
not every node processes all client protocols:



non-CASP node: regular router
omnivorous: processes all CASP messages
selective: bypassed by CASP messages with unknown client
protocols
CASP network model – out-ofpath
Bandwidth broker
NAC
CASP
AS15465
AS 1249
AS17
data






Also route network-by-network
can combine router-by-router with out-of-path messaging
Not well defined if several in one AS
basically, an inter-domain service location problem
IETF tool kit for distributed solutions:
 SLP (with extension in progress)
 DNS SRV/NAPTR (see SIP)
Probably not: multicast, anycast, LDAP
CASP protocol structure
client layer
(C)

messaging layer
messaging layer
(M)
(M)
transport layer
UDP
(T)
IP router alert
client layer does the real work:




scout protocol
reserve resources
open firewall ports
…
messaging layer:


establishes and tears down state
negotiates features and capabilities

transport layer:

reliable transport
CASP messages

Regular CASP messages



Scout messages



establish or tear down state
carry client protocol
discover next hop
Hop-by-hop reliability
Generated by any node along the chain
Message forwarding

Route stateless or state-full:



Destination:






stateless: record route and retrace
state-full: based on next-hop information in CASP node
address  look at destination address
address + record  record route
route  based on recorded route
state forward  based on next-hop state
state backward  based on previous-hop state
State:



no-op  leave state as is
ADD  add message (and maybe client) state
DEL  delete message state
Next-node discovery: pathcoupled

Discovery behavior options:


NI
straight-through
hop-by-hop
NE





non
NE
routing protocol with probing
service discovery, e.g., SLP
first hop, e.g., router advertisements
DHCP
scout protocol
NE
NR
Next-node discovery: pathcoupled
hop-by-hop discovery (“incremental”)
NI
NE
non
NE
NE
NR
Combining flow-through and
transport sessions
NI
NE
use existing transport
connection if available
non
NE
NE
NR
Mobility and route changes
DEL (B=2)
discovers new route
B=1
on refresh
ADD
B=2



avoids session identification by end point addresses
avoid use of traffic selector as session identifier
remove dead branch
SIP resilience

Similar to DNS  provide multiple servers, on
different networks


failover via DNS SRV/NAPTR
with state replication


database replication may be too heavy-weight
copy REGISTER to all backup proxies



copy service logic, configuration to other servers
minimize call state bound to one server


issue: digest authentication  third-party authentication
specify server cluster as Route, not one server
SCTP between servers for failover
CASP & IMS

Suitable for




RAN resource reservation
air interface control?
edge resource reservation
MIDCOM-style services