RFC3261 (Almost) Robert Sparks

SIPiT 10 2 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 3 Others from the bundle RFC 3262 : Reliability of Provisional Responses in SIP RFC 3263 : SIP: Locating SIP Servers RFC 3264 : An Offer/Answer Model with SDP RFC 3265 : SIP-Specific Event Notification RFC 3266 : Support for IPv6 in SDP 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 4 Most Significant Changes Since December Loose Routing S/MIME TLS (sips:) mandatory for proxy/redirect/registrar TCP mandatory for UA

SIPiT 10 5 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. A B C D INVITE B Route C,D INVITE C Route D INVITE D

SIPiT 10 6 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. A B C D INVITE D Route B,C INVITE D Route C INVITE D

SIPiT 10 7 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 8 Loose Routing - Example U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements. The INVITE arriving at U2 contains INVITE SIP/2.0 Contact: Record-Route: U2 sends a BYE BYE SIP/2.0 Route:

SIPiT 10 9 Loose Routing - Example U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements. P4 receives BYE SIP/2.0 Route: And sends BYE sip:p3.middle.com SIP/2.0 Route:

SIPiT 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: And sends BYE sip:p2.example.com;lr Route: P2 sees a URI it provided in the RURI so it rewrites this to BYE Route: And sends it to P1

SIPiT Loose Routing - Example U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements. P1 Receives BYE Route: And sends BYE

SIPiT 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 Body Signature

SIPiT 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 TCP Mandatory for UA Prevents UDP fragmentation Provides congestion control for large messages Establishes a connection for the transport of large responses 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.

SIPiT 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 Useful Resources IETF Main Website : Draft Repository : SIP Main Website : SIP Supplementary Website : Analogous pages exist at for SIPPING and SIMPLE Mailing lists: See the main IETF website for instructions on joining the SIP, SIPPING, or SIMPLE mailing lists See

Information Resource Robert Sparks