RFC3261 (Almost)

Robert Sparks
Status of the New SIP RFC
 Passed IETF Last Call

 In the RFC Editor queue

 Author’s 48 hours review imminent

 IMPORTANT: RFC3261 does not officially exist yet, only the number
has been assigned – do not refer to it in papers/documentation until it
appears in the RFC archive.
 Until then, refer to draft-ietf-sip-rfc2543bis-09.txt

SIPiT 10
2
Others from the bundle
 RFC 3262 : Reliability of Provisional Responses in SIP
<draft-ietf-sip-100rel-06.txt>
 RFC 3263 : SIP: Locating SIP Servers
<draft-ietf-sip-srv-06.txt>
 RFC 3264 : An Offer/Answer Model with SDP
<draft-ietf-mmusic-sdp-offer-answer-02.txt>
 RFC 3265 : SIP-Specific Event Notification
<draft-ietf-sip-events-05.txt>
 RFC 3266 : Support for IPv6 in SDP
<draft-ietf-mmusic-sdp-ipv6-02.txt>
 IMPORTANT: These numbers are assigned, but the RFCs do not yet
exists. Do not refer to them until they appear in the RFC archive.

SIPiT 10
3
Most Significant Changes Since December
 Loose Routing

 S/MIME

 TLS (sips:) mandatory for proxy/redirect/registrar

 TCP mandatory for UA

SIPiT 10
4
Loose Routing – The Problem
 Needed a way to specify a set of proxies for a dialog’s initial request
to traverse.
 “Strict” routing (Route/Record-Route as defined in bis-05 and before)
was too strict. Service logic could not affect routing of the initial
request.
 Strict routing conflates the request target with the next hop
destination.
 Strict route processing throws away the information in the received Request-URI.
 Behavior of UAs with default-outbound-proxies problematic.
 Brittle system failure if any element misroutes.

INVITE B INVITE C INVITE D

A B C D
Route C,D Route D

SIPiT 10
5
Loose Routing – The Solution
 Define Routing the “right” way – clean slate design

 Keep request target and next route destination separate

 Allow each route destination to determine when it has been reached

 Then add mechanism to provide backwards-compatibility with strict

routing SIP elements
 Support for loose routing is indicated through an “;lr” parameter.

INVITE D INVITE D INVITE D

A B C D
Route B,C Route C

SIPiT 10
6
Loose Routing – Processing Instructions
 If you are a strict router, follow old (bis-05) Route/Record-Route rules

 If the RURI of a request matches a URI you have previously placed in a

Record-Route header field, the previous element is a strict router.
Rewrite the message to repair what it did before further processing:
 Move the last Route hvf into the RURI.

 If A Route header field exists in a message you are about to send:

 If the top Route header field value (hfv) matches you, remove it.
 If the new top Route header field value indicates loose route support,
forward the request to it.
 Otherwise, specially prepare the message to survive a strict router
 Place RURI in the Route header as the last hfv.
 Place the first hfv into the RURI.
 Forward the request based on the RURI

SIPiT 10
7
Loose Routing - Example
U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements.
The INVITE arriving at U2 contains
INVITE sip:[email protected] SIP/2.0
Contact: sip:[email protected]
Record-Route: <sip:p4.domain.com;lr>
Record-Route: <sip:p3.middle.com>
Record-Route: <sip:p2.example.com;lr>
Record-Route: <sip:p1.example.com;lr>

U2 sends a BYE
BYE sip:[email protected] SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
SIPiT 10
8
Loose Routing - Example
U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements.
P4 receives
BYE sip:[email protected] SIP/2.0
Route: <sip:p4.domain.com;lr>
Route: <sip:p3.middle.com>
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>

And sends
BYE sip:p3.middle.com SIP/2.0
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>

SIPiT 10
9
Loose Routing - Example
U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements.
P3 receives
BYE sip:p3.middle.com SIP/2.0
Route: <sip:p2.example.com;lr>
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>
And sends
BYE sip:p2.example.com;lr
Route: <sip:p1.example.com;lr>
Route: <sip:[email protected]>

P2 sees a URI it provided in the RURI so it rewrites this to

BYE sip:[email protected]
Route: <sip:p1.example.com;lr>

And sends it to P1
SIPiT 10
10
Loose Routing - Example
U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements.
P1 Receives
BYE sip:[email protected]
Route: <sip:p1.example.com;lr>

And sends
BYE sip:[email protected]

SIPiT 10
11
S/MIME
 Provides end-to-end security of message body and/or headers.

 Certificate identified by end user address

 Public key can be transported in SIP

 Entire message can be protected by “tunneling” the message in an

S/MIME body

Header Fields

Header Fields

Body

Signature

SIPiT 10
12
TLS and sips:
 Implementation of TLS is mandatory for proxies, redirect servers and
registrars
 The ;transport=tls URI parameter value is deprecated

 A sips: URI scheme (otherwise identical to the sip: scheme) indicates

that all hops between the requestor and the resource identified by the
URI must be encrypted with TLS.
 If the request is retargeted once the resource is reached, it must use
secured transports.

SIPiT 10
13
TCP Mandatory for UA
If a request is within 200 bytes of the path
MTU, or if it is larger than 1300 bytes and
the path MTU is unknown, the request
MUST be sent using TCP.

 Prevents UDP fragmentation

 Provides congestion control for large messages

 Establishes a connection for the transport of large responses

SIPiT 10
14
Progressing to Draft Standard
 ID -> Proposed Standard -> Draft Standard -> STD

 Must provide Interop Statement

 For each feature in the specification, two independent interoperable
implementations must exist
 Any features not meeting that requirement must be removed from the
specification
 SIPiT is a natural place to gather interop statements.

SIPiT 10
15
Useful Resources
 IETF Main Website : http://www.ietf.org

 Draft Repository : http://www.ietf.org/internet-drafts

 SIP Main Website : http://www.ietf.org/html-charters/sipwg.html

 SIP Supplementary Website : http://www.softarmor.com/sipwg

 Analogous pages exist at www.ietf .org for SIPPING and SIMPLE

 Mailing lists:
 See the main IETF website for instructions on joining the SIP, SIPPING, or
SIMPLE mailing lists
 See http://cs.columbia.edu/~hgs/sip/

SIPiT 10
16
Information Resource

Robert Sparks
+1 972 473 5467
sip:[email protected]
email:[email protected]