1 / 6

Routing Mid-Dialog Requests with Outbound Extension

This document discusses the requirements and presents a solution for routing mid-dialog requests in the presence of multiple Edge Proxies using the Outbound extension in SIP.

hortonb
Download Presentation

Routing Mid-Dialog Requests with Outbound Extension

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Use Case for Mid Dialog Request Routing with Outbound(draft-johns-sip-outbound-middialog-draft-00) July 10, 2006 Sumanth Channabasappa (sumanth@cablelabs.com) (on behalf of Kevin Johns)

  2. Introduction • [OUTBOUND] (draft-ietf-sip-outbound-nn, “Managing Client Initiated Connections in the Session Initiation Protocol”) describes extensions to the Session Initiation Protocol (SIP) to support NAT traversal • defines behaviors for User Agents, registrars and proxy servers that allow dialog initiating requests to be delivered on existing flows established by the User Agent • However, routing of mid-dialog requests over an existing flow is explicitly placed out of scope by [OUTBOUND] • “draft-johns-sip-outbound-middialog-draft-00” attempts to highlight some of the requirements for routing of mid-dialog requests when using [OUTBOUND] and presents a solution based on existing procedures defined in [OUTBOUND]

  3. Use Case 1 • Edge Proxy (Edge Proxy 1) used to setup a dialog adds a Record-Route header during the dialog establishment Assumption: The URI inserted by Edge Proxy 1 resolves to multiple IP addresses • For the case of session termination: • The caller sends a BYE to Edge Proxy 1 • After a period of unresponsiveness (Edge Proxy 1 fails), the caller sends a BYE to the next Edge Proxy (Edge Proxy 2) identified by the DNS lookup • Upon receipt of the BYE: • Edge Proxy 2 attempts to forward the BYE based on the request URI (as the route header will not identify a specific flow) • The request URI identifies the callee based on the provided contact address • If the callee is behind a NAT device, the contact address will most likely be an IP Address containing the callee’s locally assigned IP Address. Since this address will not be routable by Edge Proxy 2, the BYE will result in an error being returned to the caller

  4. Use Case 2 • Edge Proxy (Edge Proxy 1) used to setup a dialog added a Record-Route header with a flow token during the dialog establishment Assumption: The URI inserted by Edge Proxy 1 resolves to multiple IP addresses • For the case of session termination: • The caller sends a BYE to Edge Proxy 1 • After a period of unresponsiveness (Edge Proxy 1 fails), the caller sends a BYE to the next Edge Proxy (Edge Proxy 2) identified by the DNS lookup • Upon receipt of the BYE: • Edge Proxy2 will attempt to forward the BYE based on the flow token in the route header rather than the request URI • Given that this flow token was generated by Edge Proxy1, Edge Proxy 2 will have no knowledge of such a flow and not be able to route the BYE. Since this address will not be routable by Edge Proxy 2, the BYE will result in an error being returned to the caller

  5. Requirements • Goal: • Support the routing of mid-dialog requests in the presence of multiple Edge Proxies which record-route at session establishment • Any solution that attempts to solve this use case should adhere to the following requirements: • The flow token remains unique to a flow, the flow can be recovered from the token, and the token can not be modified by attackers (this requirement is taken from Outbound); • Work for the case where the SIP UA registers multiple AORs from the same contact or different contact. • Others?

  6. Next Steps • Should the WG consider routing of mid-dialog request over an existing flow as a WG item?

More Related