[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Dispatch Working Group                                     A. Allen, Ed.
Internet-Draft                                                Blackberry
Intended status: Informational                            March 11, 2014
Expires: September 12, 2014


  Indicating that out of dialog requests related to an existing dialog
                   must be routed via an intermediar
         draft-allen-dispatch-routing-out-of-dialog-request-00

Abstract

   This document discusses the problems for out of dialog requests that
   are related to another dialog, caused by B2BUA intermediaries that
   modify SIP parameters or terminate dialogs and proposes some possible
   solutions.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 12, 2014.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Allen                  Expires September 12, 2014               [Page 1]


Internet-Draft           Out of dialog requests               March 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3

   2.  Problem statement . . . . . . . . . . . . . . . . . . . . . . . 3

   3.  Potential solutions . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  New SIP header field  . . . . . . . . . . . . . . . . . . . 4
     3.2.  New rr-param  . . . . . . . . . . . . . . . . . . . . . . . 4
     3.3.  New URI parameter . . . . . . . . . . . . . . . . . . . . . 4
     3.4.  New Feature Capability Indicator  . . . . . . . . . . . . . 5
     3.5.  Option Tag  . . . . . . . . . . . . . . . . . . . . . . . . 5

   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5

   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5

   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5

   7.  Informative References  . . . . . . . . . . . . . . . . . . . . 6

   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6





























Allen                  Expires September 12, 2014               [Page 2]


Internet-Draft           Out of dialog requests               March 2014


1.  Introduction

   In RFC 3265 [1] and RFC 3515 [2] SUBCRIBE requests and REFER requests
   were allowed to reuse a dialog created by another SIP method (e.g.
   INVITE).  RFC 6665 [3] has deprecated such dialog reuse due to all
   the problems that dialog reuse caused.  However some B2BUA
   intermediaries change parameters in SIP requests or terminate dialogs
   and need to receive the SUBSCRIBE and REFER requests that relate to
   an existing dialog that is record routed via the B2BUA.


2.  Problem statement

   SIP sessions often involve intermediaries acting as B2BUAs that in
   addition to forwarding SIP requests and responses also act as UAs to
   perform more complex manipulations of the session.  Such
   manipulations include modifying URIs in the Request-URI, Contact
   address or other header fields and even terminating the dialog for
   some mid session requests (for example performing a session transfer
   when receiving a REFER request rather than forwarding the REFER
   request to the remote UAS).

   Typically such functionality has been achieved by sending REFER and
   SUBSCRIBE requests within the established dialog for the session,
   with the intermediary then intercepting the REFER or SUBSCRIBE
   request and then either modifying to conform to the expected view of
   the remote UAS or processing the REFER or SUBSCRIBE request rather
   than forwarding it to the remote UAS.  However such dialog reuse has
   been problematic and RFC 6665 [3] has deprecated dialog reuse (except
   for legacy interoperability).

   However, if REFER and SUBSCRIBE requests are sent outside the related
   existing dialog then the requests will not be routed by the
   manipulating B2BUA and thus will either to fail to arrive at the
   remote UA due to URI manipulations or fail at the remote UA because
   parameters in the request (e.g Target-Dialog, Replaces, Refer-To URI,
   etc) do not match the values at the remote UAS.
   draft-kaplan-dispatch-gruu-problematic-00 [4] further describes some
   of the problems if a GRUU is used as the Request-URI of a related out
   of dialog request.

   One way B2BUAs have have addressed this problem is by acting as two
   UAs back-to-back with the Contact URI being overwritten to be the URI
   of the B2BUA.  However this means that GRUU of the UA is overwritten
   by the B2BUA and the meaning of the Contact header field parameters
   becomes obscure.  Do the Contact header field parameters reflect the
   capabilities of the Contact address (i.e the B2BUA) or do they
   reflect the capabilities of the remote UA?  If they relect the



Allen                  Expires September 12, 2014               [Page 3]


Internet-Draft           Out of dialog requests               March 2014


   capabilities of the B2BUA then the identfication of the capabilities
   of the remote UAS has been lost.  If they reflect the capabilities of
   the remote UA then they falsely identify that the B2BUA contact
   address has the capabilities of the remote UA.

   What is needed is a way for intermediaries that need to receive and
   manipulate or process mid session requests to indicate that mid
   session out of dialog requests that relate to the dialog of the
   session being established, to indicate a URI to be included in the
   Route header of such out of dialog requests so that the request will
   route by the intermediary.


3.  Potential solutions

3.1.  New SIP header field

   A new SIP header field (e.g.  OOD-Record-Route) could be defined
   which contains the URI of the intermediary for routing out of dialog
   requests that relate to another dialog.  The intermediary would
   include the new header field containing the URI that the intermediary
   requires related out of dialog requests to be routed to in the
   requests and responses at dialog establishment.  The UA would then
   include a Route header field containing the URI received in the new
   header field in any related out of dialog requests it sends.

3.2.  New rr-param

   A new rr-param(e.g.  OOD-RR) could be defined which indicates that
   this is the URI of the intermediary for routing out of dialog
   requests that relate to another dialog.  The intermediary would
   include the new rr-param when including its URI in the Record-Route
   header field.  The UA would then include a Route header field
   containing the URI with the associated new rr-param received in the
   Record-Route header field in any related out of dialog requests it
   sends.

3.3.  New URI parameter

   A new URI parameter (e.g.  OOD-RR) could be defined which indicates
   that this is the URI of the intermediary for routing out of dialog
   requests that relate to another dialog.  The intermediary would
   include the new URI parameter when including its URI in the Record-
   Route header field.  The UA would then include a Route header field
   containing the URI with the new URI parameter received in the Record-
   Route header field in any related out of dialog requests it sends.





Allen                  Expires September 12, 2014               [Page 4]


Internet-Draft           Out of dialog requests               March 2014


3.4.  New Feature Capability Indicator

   RFC 6809 [5] defines the Feature-Caps header field for intermediaries
   to include Feature-Capability indicators indicating the capabilities
   they support.  A new feature-capability indicator (e.g. sip.ood-
   route) could be defined which contains the URI of the intermediary
   for routing out of dialog requests that relate to another dialog.
   The intermediary would include a Feature-Caps header field containing
   the Feature-Capability indicator with the URI that the intermediary
   requires related out of dialog requests to be routed to in the
   requests and responses at dialog establishment.  The UA would then
   include a Route header field containing the URI received in the
   Feature-Capability indicator in any related out of dialog requests it
   sends.

3.5.  Option Tag

   A new SIP option tag will be needed for a UA to indicate that it
   supports the new extension so that the the intermediary can use the
   new mechanism instead of other approaches that modify the contact
   address and force dialog reuse.  SIP OPTIONS method could be used by
   the intermediary to determine whether the UAS supports the extension
   before forwarding the dialog creating request.  Alternatively the
   intermediary might modify the dialog after discovering in a response
   whether the UAS supports the new extension or not.


4.  Security Considerations

   The capability to include a URI in a request or response which will
   cause a UA to route other requests via the intermediary provides the
   possibility to create man-in-the-middle attacks.  However this is
   also true of existing SIP header fields like Record-Route.  The same
   considerations apply as those to the use of Record-Route header
   fields.


5.  IANA Considerations

   This document does not currently have anything requiring action by
   IANA.


6.  Acknowledgements

   TBD.





Allen                  Expires September 12, 2014               [Page 5]


Internet-Draft           Out of dialog requests               March 2014


7.  Informative References

   [1]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
        Notification", RFC 3265, June 2002.

   [2]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
        Method", RFC 3515, April 2003.

   [3]  Roach, A., "SIP-Specific Event Notification", RFC 6665,
        July 2012.

   [4]  Kaplan, H., "Problems with the SIP Globally Routable User Agent
        URIs (GRUUs)", Internet
        Draft draft-kaplan-dispatch-gruu-problematic-00, October 2010.

   [5]  Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
        Indicate Support of Features and Capabilities in the Session
        Initiation Protocol (SIP)", RFC 6809, November 2012.


Author's Address

   Andrew Allen (editor)
   Blackberry
   1200 Sawgrass Corporate Parkway
   Sunrise, Florida  33323
   USA

   Email: aallen@blackberry.com






















Allen                  Expires September 12, 2014               [Page 6]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/