Internet DRAFT - draft-jesske-straw-forking-correlation

draft-jesske-straw-forking-correlation







Network Working Group                                          R. Jesske
Internet-Draft                                          Deutsche Telekom
Intended status: Informational                              July 4, 2014
Expires: January 5, 2015


Correlation of multiple responses of forked INVITES in Back to Back User
                                 Agents
               draft-jesske-straw-forking-correlation-00

Abstract

   This document describe how a correlation of multiple resonses of a
   forked INVITE in Back to Back User Agents can apply.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 January 5, 2015.

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



Jesske                   Expires January 5, 2015                [Page 1]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   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.

Table of Contents

   1.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements on forking in SIP networks interconnecting
           with other SIP networks . . . . . . . . . . . . . . . . .   3
     1.2.  SIP signalling procedures under consideration for forking
           use cases . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.3.  Normal Forking use case . . . . . . . . . . . . . . . . .   4
     1.4.  Forking with provisional responses with SDP . . . . . . .   6
     1.5.  Forking use case with provisional responses with SDP  . .   7
     1.6.  Forking use case where 100 rel is used  . . . . . . . . .   7
     1.7.  Forking use case where preconditions are used . . . . . .   7
     1.8.  Forking use case with early media played  . . . . . . . .   7
   2.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     5.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Appendix A.  An Appendix  . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Problem Statement

   The world of SIP networks is steadily growing.  SIP networks based on
   IETF RFC 3261 also networks of operators based on 3GPP IMS or ETSI
   TISPAN NGN and many others are existing.  Now connecting this
   networks may result in problems of interoperability.  One main
   problem is the SIP basic feature forking which allows to spread the
   INVITE request towards multiples registered UA's for one identity.
   Nevertheless the forking feature described in RFC3261 [RFC3261] which
   allows to reach more than one target which is registered under the
   same identity but at diffrent locations is not really supported by
   all UAC and also not by networks having B2BUA's (e.g.  PSTN
   interwoking Gateways or Session Boader Controler) in the path.
   Forking itself apply when Bob is registering his home phone and his
   SIP client on his notebook with the same identity.  This INVITE will
   now be sent to both enddevices.  And each end device will answer with
   a provisional response (e.G. 180 ringing) or a final response.

   Now the originating SIP device has to understand that two devices are
   ringing and one will answer the call.  No Problem since RFC3261
   [RFC3261] allows this and allows also the originating device to



Jesske                   Expires January 5, 2015                [Page 2]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   handle multiples responses.  But this is not mandated by RFC3261
   [RFC3261] and ted to implementers choice.  There will the first
   problem apply that only one of the Responses will be taken into
   consideration.

   With further features like Preconditions and reliability of
   provisional responses the UAC has to reserve resources for one or
   both of the responses and opens a early dialog.  And has to choose
   which of the dialogs should be reserved when not supporting multiples
   early dialogs.  Thus a spread of problems arise with such behavior.

   This document will describe how a correlation for multiples early
   dialogs and other received Responses can done within a B2BUA as
   described in the taxonomy document RFC7029 [RFC7029] The role of the
   B2BUA is a Signaling/Media Plane B2BUA Role.  Thus many possible use
   cases which will be possible looking on the used features are
   considered in this document

1.1.  Requirements on forking in SIP networks interconnecting with other
      SIP networks

   To provide the best user behavior a service provider shall have the
   possibility to correlate multiples received responses to one dialog
   leg to the UAC.

   The B2BUS providing such possibility must have to understand where
   the SIP dialog request is coming from and if this originating network
   or entity or UA can or cannot support multiples responses.

   The main requirement is to have an entity that can receive multiples
   responses from forked INVITES which now can be correlated to one
   single dialog towards the originating entity.

   To act proactive the B2BUA should also be possible to include and
   handle the no-for directive based on the originating and terminating
   network.

1.2.  SIP signalling procedures under consideration for forking use
      cases

   SIP defined in RFC3261 [RFC3261]describes how forking should apply.
   Also rules for UA for responses and merged requests are defined.  But
   it is not stated how a forking correlation should apply and what is
   needed.  There are further documetns which are describing the
   reliability of provisional Responses RFC3262 [RFC3262]and the
   Precondition mechanism in RFC3312 [RFC3312].  In both documents a
   further description of forking relevant issues are missing.




Jesske                   Expires January 5, 2015                [Page 3]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   Further mechanisms to express caller preferences defined in RFC3841
   [RFC3841].  This RFC defines a method to signal the "fork-directive"
   to indicate that the UAC will not have a forking in the forwarding
   path.  This directive is a optional SIP feature which is not
   implemented in each SIP network.  The Request Disposition header
   contains the regarding directive which is requested by the User
   Agent.

   To avoid too many forkings (possible early Dialogs) RFC5393 [RFC5393]
   defines the Max-Breadth header to avoid to many forked Requests.  But
   there is no effect on correlating the responses.  This helps to
   reduce a cascading of multiples forkings in the forward path.  The
   number in the header gives the maximum branches (parallel possible
   early dialogs) of a forked request.  Exceeding the maximum will
   result in error responses 440

   RFC6228 [RFC6228]defines a new response code to close early dialogs
   proper.  In case where a forking proxy realizes that a 200 OK has
   been processed the proxy can sent 199 responses to the other open
   dialogs.  This helps in case of correlation when early dialogs has
   been sent till the end user.

   RFC3326 [RFC3326] defines the Reason header and describes one use
   because in case the INVITE is forked and results in a rejection, the
   error response may never be forwarded to the client unless all the
   other branches also reject the request.  This problem is known as the
   "Heterogeneous Error Response Forking Problem", or HERFP.  It is
   foreseen that a solution to this problem may involve encapsulating
   the final error response in a provisional response.  The Reason
   header field is a candidate to be used for such encapsulation.  In
   this case the forking proxy will release the dialogs.

1.3.  Normal Forking use case

   SIP defined in RFC3261 [RFC3261]describe how forking should apply.
   Also rules for UA for responses and merged requests are defined.  But
   it is not stated how a forking correlation should apply and what is
   needed.  There are further document













Jesske                   Expires January 5, 2015                [Page 4]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   .

        UAC           Proxy    Forking Proxy       UAS_2   UAS_3   UAS_4
           |             |             |                |       |       |
           |-- INVITE -->|             |                |       |       |
           |             |-- INVITE -->|-- INVITE (2) ->|       |       |
           |             |             |-- INVITE (3) --------->|       |
           |             |             |-- INVITE (4) ----------------->|
           |             |             |<-- 18x (2) ----|       |       |
           |<- 18x (2) --|<- 18x (2) --|                |       |       |
           |             |             |<-- 18x (3) ------------|       |
           |<- 18x (3) --|<- 18x (3) --|                |       |       |
           |             |             |<-- 18x (4) --------------------|
           |<- 18x (4) --|<- 18x (4) --|                |       |       |
           |             |             |                |       |       |
           |             |             |<-- 200 (4) --------------------|
           |             |<- 200 (4) --|                |       |       |
           |<- 200 (4) --|             |                |       |       |
           |-- ACK (4) ->|             |                |       |       |
           |             |--- ACK (4) >|                |       |       |
           |             |             |--- ACK (4) ------------------->|
           |- CANCEL (2)>|             |                |       |       |
           |             |- CANCEL (2)>|                |       |       |
           |             |             |--CANCEL (2)--->|       |       |
           |             |             |<-- 200 (2) ----|       |       |
           |             |<- 200 (2) --|                |       |       |
           |<- 200 (2) --|             |                |       |       |
           |- CANCEL (3)>|             |                |       |       |
           |             |- CANCEL (3)>|                |       |       |
           |             |             |--- CANCEL(3) --------->|       |
           |             |             |                |       |       |
           |             |             |<-- 200 (3) ------------|       |
           |             |<- 200 (3) --|                |       |       |
           |<- 200 (3) --|             |                |       |       |

               Figure 1: Example Call Flow Forking



   As you can see, this figure shows the normal forking case where each
   UA sends a 18x either with or without SDP.  UAS_4 sends a final
   response and the UAC has to cancel all other open provisional
   responses.

   Further possible scenarios are that two or three UAS will answer the
   call with 200 in time so that the UAC has now three open sessions
   which is not really the goal when a user would like to communicate
   with only one person.



Jesske                   Expires January 5, 2015                [Page 5]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   Figure 1 shows an normal example of forking.  With receiving 18x the
   UAC has to open transaction. where UAS_2 and UAS_3 does reject the
   call with a 4xx.  So only UAA_4 answers the dialog correctly.

1.4.  Forking with provisional responses with SDP

   This section describes the use case where multiples 18x responses are
   sent back with different SDP in the responses.  This use case appear
   when the UAS instances where the INVITE is forked to will use
   different codecs.  E.G one UA is a video phone answering with a video
   codec the other one a mobile phone and a further one using a DECT
   entity

   .

        UAC             B2BUA    Forking Proxy       UAS_2   UAS_3   UAS_4
           |             |             |                |       |       |
           |-- INVITE -->|             |                |       |       |
           |             |-- INVITE -->|-- INVITE (2) ->|       |       |
           |             |             |-- INVITE (3) --------->|       |
           |             |             |-- INVITE (4) ----------------->|
           |             |             |<-- 18x (2) ----|       |       |
           |<- 18x (2) --|<- 18x (2) --|                |       |       |
           |             |             |<-- 18x (3) ------------|       |
           |<-UPDATE (3)-|<- 18x (3) --|                |       |       |
           |-- 200 (3) ->|             |                |       |       |
           |             |             |<-- 18x (4) --------------------|
           |<-UPDATE (4)-|<- 18x (4) --|                |       |       |
           |             |             |                |       |       |
           |-- 200 (4) ->|             |                |       |       |
           |             |             |<-- 200 (4) --------------------|
           |             |<- 200 (4) --|                |       |       |
           |<- 200 (4) --|             |                |       |       |
           |-- ACK (4) ->|             |                |       |       |
           |             |--- ACK (4) >|                |       |       |
           |             |             |--- ACK (4) ------------------->|



                       Figure 2: Example Call Flow




   With arriving a new 18x with additional codecs included have to
   result in an UPDATE containing the SDP of the preceding 18x.  The
   important fact is that the B2BUA has to anchor the media plane as
   well as acting as signalling B2BUA.



Jesske                   Expires January 5, 2015                [Page 6]

Internet-Draft     forking answer correlation in B2BUA         July 2014


1.5.  Forking use case with provisional responses with SDP

   This section describes the use case where multiples 18x responses are
   sent back with different SDP content.  This use case appear when the
   UAS instances where the INVITE is forked to will use different
   codecs.  E.G one UA is a video phone answering with a video codec the
   other one a mobile phone and a further one using a DECT entity

1.6.  Forking use case where 100 rel is used

   This section describes the use case where multiples 18x responses are
   sent back with different SDP content.  And in addition one or more
   UAS will require reliability of provisional responses.  Please Note
   that such a behavior could be cause by an application server playing
   specific announcements

   There is the possibility based on the request if the 100rel mechanism
   will only be used between B2BUA and UAS or really end to end.  In
   case where the 100rel is stated as supported it is not mandatory to
   use it.  In that case where a 18x is sent back with a 100rel required
   then the B2BUA can play the role of anchoring the media and apply the
   100rel between B2BUA and UAS and let the UAC to B2BUA connection as
   unreliable.

   Where the B2BUA decides to path the required 100rel the UAC will send
   then the PRACK and waits for the 200 OK.  In case there are further
   18x with other type of SDP arriving at the B2BUA the UAC needs to be
   informed about change of codec.  The UAC has again to sent the PRACK.

1.7.  Forking use case where preconditions are used

   This use case describes the case where preconditions will be used.
   This apply in mobile networks where resource reservation is used.
   The Precondition mechanism in RFC3312 [RFC3312] shows the needed
   additional procedures.  A B2BUA doing correlation in between to
   allows only one early dialog sent back to the UAC.  The B2BUA has to
   anchor the SIP Dialogs as well as the media reservation streams.

1.8.  Forking use case with early media played

   This use case describes the case where early media is played due to
   application server actions. e.g playing a ringtone or a specific
   announcement sent back.








Jesske                   Expires January 5, 2015                [Page 7]

Internet-Draft     forking answer correlation in B2BUA         July 2014


2.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

3.  Security Considerations

4.  Acknowledgements

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3262]  Rosenberg, J. and H. Schulzrinne, "Reliability of
              Provisional Responses in Session Initiation Protocol
              (SIP)", RFC 3262, June 2002.

   [RFC3312]  Camarillo, G., Marshall, W., and J. Rosenberg,
              "Integration of Resource Management and Session Initiation
              Protocol (SIP)", RFC 3312, October 2002.

   [RFC3326]  Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
              Header Field for the Session Initiation Protocol (SIP)",
              RFC 3326, December 2002.

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.

   [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,
              "Addressing an Amplification Vulnerability in Session
              Initiation Protocol (SIP) Forking Proxies", RFC 5393,
              December 2008.

   [RFC6228]  Holmberg, C., "Session Initiation Protocol (SIP) Response
              Code for Indication of Terminated Dialog", RFC 6228, May
              2011.




Jesske                   Expires January 5, 2015                [Page 8]

Internet-Draft     forking answer correlation in B2BUA         July 2014


   [RFC7029]  Hartman, S., Wasserman, M., and D. Zhang, "Extensible
              Authentication Protocol (EAP) Mutual Cryptographic
              Binding", RFC 7029, October 2013.

5.2.  Informative References

   [TS24.229]
              3GPP, "IP multimedia call control protocol based on
              Session Initiation Protocol (SIP) and Session Description
              Protocol (SDP); Stage 3", March 2014.

Appendix A.  An Appendix

Author's Address

   Roland
   Deutsche Telekom
   Heinrich-Herz-Str. 3-7
   Darmstadt  64307
   Germany

   Phone: +49 6151 581 2766
   Email: r.jesske[AT]telekom[DOT]de




























Jesske                   Expires January 5, 2015                [Page 9]