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]
