1. RFC3261 (Almost) Robert Sparks

2. 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

3. 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.

4. SIPiT 10 4 Most Significant Changes Since December Loose Routing S/MIME TLS (sips:) mandatory for proxy/redirect/registrar TCP mandatory for UA

5. 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

6. 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

7. 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

8. 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:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: U2 sends a BYE BYE sip:caller@u1.example.com SIP/2.0 Route:

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

10. SIPiT 10 10 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 sip:caller@u1.example.com Route: And sends it to P1

11. SIPiT 10 11 Loose Routing - Example U1->P1->P2->P3->P4->U2 : All but P3 are loose routing elements. P1 Receives BYE sip:caller@u1.example.com Route: And sends BYE sip:caller@u1.example.com

12. SIPiT 10 12 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

13. SIPiT 10 13 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.

14. SIPiT 10 14 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.

15. SIPiT 10 15 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.

16. SIPiT 10 16 Useful Resources IETF Main Website : http://www.ietf.orghttp://www.ietf.org Draft Repository : http://www.ietf.org/internet-draftshttp://www.ietf.org/internet-drafts SIP Main Website : http://www.ietf.org/html-charters/sipwg.htmlhttp://www.ietf.org/html-charters/sipwg.html SIP Supplementary Website : http://www.softarmor.com/sipwghttp://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/

17. Information Resource Robert Sparks +1 972 473 5467 sip:rsparks@dynamicsoft.com email:rsparks@dynamicsoft.com