Correlation of multiple responses of forked INVITES in Back to Back User Agents
draft-jesske-dispatch-forking-answer-correlation-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Roland Jesske | ||
| Last updated | 2014-10-27 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jesske-dispatch-forking-answer-correlation-02
Network Working Group R. Jesske
Internet-Draft Deutsche Telekom
Intended status: Informational October 27, 2014
Expires: April 30, 2015
Correlation of multiple responses of forked INVITES in Back to Back User
Agents
draft-jesske-dispatch-forking-answer-correlation-02
Abstract
This document describe how a correlation of multiple responses 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 April 30, 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 April 30, 2015 [Page 1]
Internet-Draft forking answer correlation in B2BUA October 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
2. Consideration of RFC's on SIP signalling procedures under
consideration for forking use cases . . . . . . . . . . . . . 4
2.1. RFC3261 Session Initiation Protocol . . . . . . . . . . . 4
2.2. RFC3262 Reliability of provisional responses . . . . . . 4
2.3. RFC3312 Integration of Resource Management and Session
Initiation Protocol (SIP) . . . . . . . . . . . . . . . . 5
2.4. RFC3841 Caller Preferences for the Session Initiation
Protocol (SIP) . . . . . . . . . . . . . . . . . . . . . 5
2.5. RFC5393 Addressing an Amplification Vulnerability in
Session Initiation Protocol (SIP) Forking Proxies . . . . 5
2.6. RFC6228 Session Initiation Protocol (SIP) Response Code
for Indication of Terminated Dialog . . . . . . . . 5
2.7. RFC3326 The Reason Header Field for the Session
Initiation Protocol (SIP) . . . . . . . . . . . . . . . . 6
2.8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Requirements on forking in SIP networks interconnecting with
other SIP networks . . . . . . . . . . . . . . . . . . . . . 6
4. Forking use cases . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Normal Forking use case . . . . . . . . . . . . . . . . . 7
4.2. Multiples provisional responses without SDP . . . . . . . 9
4.3. Forking use case with provisional responses with SDP
using 100rel . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Forking use case with provisional responses with SDP
using 100rel and preconditions . . . . . . . . . . . . . 13
4.5. Forking use case with early media played . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23
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 these
networks may result in problems of interoperability. One main
Jesske Expires April 30, 2015 [Page 2]
Internet-Draft forking answer correlation in B2BUA October 2014
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 and which is registered under
the same identity but at different locations is not really supported
by all UAC in that way that a connection between UAC and one of the
UAS will succeed in a successful communication even one of the UAS
sends a 200 OK for the INVITE. This apply also to networks having
B2BUA's (e.g. PSTN interwoking Gateways or Session Border
Controller) in the path which should understand multiples responses
and handle it correctly.
This could result in many SIP early Dialogs that will never
established due to the applicability of the UAC to receive multiples
early dialogs.
RFC3261 [RFC3261] indicates how the UAC must/should/may behave (some
aspects updated by RFC6026 [RFC6026] and RFC6141 [RFC6141]); this
includes the impacts of receiving INVITE's 18x or 2xx on a known or
unknown dialog. However, it frequently defers the human interaction
decisions to the implementor.
Similarly, a device can be fully compliant with RFC3261 [RFC3261] but
decide to have a service to terminate call after or before answer (or
individual early dialogs before answer) if more than 1 dialog was
observed during call setup. Such a "service" likely indicates that
the device doesn't really support forking proxies (or maybe doesn't
trust forking interactions).
One use case is when the UAC will alway ever apply to the first
received provisional response and wait for a final response for the
certain provisional response.
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 end devices. 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
handle multiples responses. But this is not mandated by RFC3261
[RFC3261] and led to implementers choice. There will the first
problem apply that only one of the Responses will be taken into
consideration for creating a dialog.
Please Note that RFC3261 [RFC3261] doesn't do require how the
responses from multiple forks are to be handled and the basic
Jesske Expires April 30, 2015 [Page 3]
Internet-Draft forking answer correlation in B2BUA October 2014
transaction and dialog semantics must be followed. But looking into
reality there are many broken clients and entities out in the world
and service provides doing forking for their customers may disappoint
them because it will not work proper and no connectivity will be
reached.
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 describes how a correlation for multiples early dialogs
and other received Responses can done within a B2BUA. The possible
roles of a B2BUA is 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
2. Consideration of RFC's on SIP signalling procedures under
consideration for forking use cases
2.1. RFC3261 Session Initiation Protocol
SIP defined in RFC3261 [RFC3261]describes how forking should apply.
Also rules for UA for responses in general and merged requests are
defined. But it is not stated how a forking correlation should apply
and what is needed.
A couple of rules with regard to non 2xx final responses apply to the
forking proxy with regard to forwarding it to the UAC. The Response-
Context defined in RFC3261 [RFC3261] will hold the received non 2xx
final responses until for all INVITE transactions a final response is
received. 1xx and 2xx response will be forwarded immediately. And
for 6xx Responses the proxy SHOULD cancel all client pending
transactions.
So with regard to non 2xx and 1xx final responses the forking proxy
has to aggregate and act as central element
2.2. RFC3262 Reliability of provisional responses
The RFC describing the reliability of provisional Responses RFC3262
[RFC3262] does not describes interactions with forking. Thus a PRACK
for provisional Response is seen as a single transaction and makes
the SDD reliable for the specific dialog. This is a end to end
behavior between the UAS and the related UAC.
Jesske Expires April 30, 2015 [Page 4]
Internet-Draft forking answer correlation in B2BUA October 2014
2.3. RFC3312 Integration of Resource Management and Session Initiation
Protocol (SIP)
Also in RFC3313 [RFC3312] describing the precondition mechanism is
not mentioning any interactions with forking relevant issues.
2.4. RFC3841 Caller Preferences for the Session Initiation Protocol
(SIP)
RFC3841 [RFC3841] describes extensions to the Session Initiation
Protocol (SIP) which allow a caller (UAC) to express preferences
about request handling in servers.
One of the caller preferences defined in RFC3841 [RFC3841]. is a
method to signal the "fork-directive" to indicate if the SIP proxy is
allowed to fork or not fork the request 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.
The parallel-directive does indicate how a SIP proxy should fork the
request. Either "parallel" or "sequential"
2.5. RFC5393 Addressing an Amplification Vulnerability in Session
Initiation Protocol (SIP) Forking Proxies
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
2.6. RFC6228 Session Initiation Protocol (SIP) Response Code for
Indication of Terminated Dialog
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.
In consideration with the rules defined in RFC3261 for forking proxy
a received non 2xx final to an initial dialog initiation request that
it recognizes as terminating one or more early dialogs associated
with the request. The forking proxy generates normally (e.g. non
Jesske Expires April 30, 2015 [Page 5]
Internet-Draft forking answer correlation in B2BUA October 2014
100rel, no final response sent) 199 response upstream for each of the
terminated early dialogs.
2.7. RFC3326 The Reason Header Field for the Session Initiation
Protocol (SIP)
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.
2.8. Conclusions
All above mentioned RFCs and procedures describes a piece of the
whole picture how forking apply and what procedures are useabel for
such cases. It is also fact that UA's and B2BUA's (e.g. PSTN GW)
are existing that will not support multiples early dialogs. Also the
support of caller preferences is not secured or implemented by UAC
and also SIP forking proxies. Service providers will provide forking
independent what the source will support or not. Thus the only
solution seen is to describe procedures which apply in B2BUA to
support an correlation of multiples early dialogs and other received
18x Responses.
3. Requirements on forking in SIP networks interconnecting with other
SIP networks
To improve interoperability with devices which do not support
forking, a service provider shall have the possibility to use a B2BUA
to multiplex multiple downstream dialogs into a single dialog toward
the caller."
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. This
could be also assumed by Service Level Agreements (SLA) between the
interconnection partners.
The main requirement is to have an entity that can receive multiples
responses based on forked INVITES which now can be correlated to one
single dialog towards the originating entity.
Jesske Expires April 30, 2015 [Page 6]
Internet-Draft forking answer correlation in B2BUA October 2014
To act proactive the B2BUA should also be possible to include and
handle preferences (e.g. non forking wished) based on the originating
and terminating network.
4. Forking use cases
4.1. 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 correlation of multiples provisional responses
should apply and what is needed. The numbers in brackets shows the
INVITES/early dialogs created.
Jesske Expires April 30, 2015 [Page 7]
Internet-Draft forking answer correlation in B2BUA October 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)--->| | |
| | |<-- 200 (2) ----| | |
| | |<-- 487 (2) ----| | |
| || |--- ACK (2)---->| | |
| | | | | |
| | |--- CANCEL(3) --------->| |
| | |<-- 200 (3) ------------| |
| | |<-- 487 (3) ------------| |
| | |--- ACK (3)------------>| |
| | | | | |
Figure 1: Example Call Flow Forking
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
forking proxy has to cancel all other open provisional responses.
The 487 is sent back to the forking proxy on each early dialog (2)
and (3) created in the UAS.
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 April 30, 2015 [Page 8]
Internet-Draft forking answer correlation in B2BUA October 2014
Figure 1 shows an normal example of forking. With receiving 18x the
UAC has to open transaction. So only UAA_4 answers the dialog
correctly. It is task of the forking proxy to cancel the remaning
open early dialogs
4.2. Multiples provisional responses without SDP
This section describes the use case where multiples 18x responses are
sent back which doesn't contain any SDP. This use case appear when
the UAS instances where the INVITE is forked without any specific
requirements and support of specific extensions like 100rel
In this specific case the B2BUA has not to anchor the media and acts
only as signalling B2BUA and has to maintain the signalling legs.
This case is only needed where it is known that the UAC cannot handle
multiples early dialogs without SDP or interconnection relations has
to grantee that only single dialoges will pass..
Jesske Expires April 30, 2015 [Page 9]
Internet-Draft forking answer correlation in B2BUA October 2014
.
UAC B2BUA Forking Proxy UAS_2 UAS_3 UAS_4
| | | | | |
|-INVITE(1)F1->| | | | |
| |- INVITE F2 -->|- INVITE F3(2)->| | |
| | |- INVITE F4(3)------->| |
| | |- INVITE F5(4)------------->|
| | |<-- 18x (2) F6--| | |
|<- 18x (1) F8-|<- 18x (2) F7 -| | | |
| | |<-- 18x (3) F9--------| |
| |<- 18x (3) F10-| | | |
| | | | | |
| | |<-- 18x (4) F11-------------|
| |<- 18x (4) F12-| | | |
| | | | | |
| | | | | |
| | |<-- 200 SDP (4)F13----------|
| |<- 200 (4) F14-| | | |
|<- 200(1) F15-| | | | |
| | |- CANCEL F16 -->| | |
| | |<- 200 (2) F17 -| | |
| | |<- 487 (2) F18 -| | |
| | |-- ACK (2) F19->| | |
| | | | | |
| | |- CANCEL (3) F20 ---->| |
| | |<----200 (3) F21 -----| |
| | |<--- 487 (3) F22 -----| |
| | |---- ACK (3) F23 ---->| |
| | | | | |
|- ACK(1) F24->| | | | |
| |- ACK (4) F26->| | | |
| | |--- ACK (4) F27------------>|
Figure 2: Example Call Flow
The B2BUA will maintain a dialog between UAC and the incoming part of
the B2BUA (UAS) And acts as UAC towards the terminating network
(UAS_2, UAS_3 and UAS_4). The INVITE F1 will have another Call-Id as
INVITE F2, also the to-tags are different.
The first 18x (F7) will be passed towards the UAC. The tags (to-tag,
from-tag), call-id etc will be stored by the B2BUA. The 18x sent
towards the UAC will contain the to-tag, Call-Id of INVITE F1 and the
from-tag is generated by the B2BUA. With arriving further 18x (F10,
F12) the B2BUA has to store the status of the to-tags etc and will
not forward the 180 to the UA. The B2BUA has not to anchor
signalling plane i.e as signalling B2BUA.
Jesske Expires April 30, 2015 [Page 10]
Internet-Draft forking answer correlation in B2BUA October 2014
With arriving arriving the 200OK (F14) at the B2BUA with the SDP sent
back form UAS_4 the B2BUA will sent a 200 OK towards the UAC. In
this case the B2BUA re-written the to-tag, from-tan and call-id as
already done for response 18x F7.
As for normal forking the forking proxy is responsible for canceling
the open dialogs with the CANCEL F16 and F20. The CANCEL will be
initiated with receiving/sending the final 200 OK response And ACK
F24 finalizes the call initiation.
4.3. Forking use case with provisional responses with SDP using 100rel
This section describes use case where reiability of provisional
responses will be used. This apply in networks where announcements
will be played in advance of call aception. The RFC describing the
reliability of provisional Responses RFC3262 [RFC3262] does not
describes interactions with forking. A B2BUA doing correlation in
between to allows only one early dialog sent back to the UAC. The
B2BUA has to anchor the other early SIP Dialogs. As long as there is
no media interaction needed the media has not to be ancored
This use case apply 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 UAS
is a video phone answering with a video codec the other one a mobile
phone and a further one using a DECT entity.
And one or more UAS will require reliability of provisional
responses. Please Note that such a behavior could be also caused by
an application server playing specific announcements which acts on
behalf of the UAS
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. When the UAS want to have the 18x reliable it will set the
100rel into the require header field. In that case where a 18x is
sent back with a 100rel required then the B2BUA may play the role of
anchoring the media and apply the 100rel between B2BUA and UAS and
let the UAC to B2BUA connection as unreliable. Please note that this
is only needed in cases where the media anchoring has to do some
manipulation of the media e.g. transcoding of codecs.
Where the B2BUA decides to pass the required 100rel header field the
UAC will send then the PRACK and waits for the 200 OK. In case there
are further 18x with equal other type of SDP arriving at the B2BUA .
B2BUA has to keep handle the 100rel and sent the PRACK to the UAS.
Jesske Expires April 30, 2015 [Page 11]
Internet-Draft forking answer correlation in B2BUA October 2014
Preconditions: INVITE 100rel supported is set and in 18x a SDP with
100rel required is sent back
.
UAC B2BUA Forking Proxy UAS_2 UAS_3 UAS_4
| | | | | |
|- INVITE F1-->| | | | |
| |- INVITE F2 -->|- INVITE F3(2)->| | |
| | |- INVITE F4(3)------->| |
| | |- INVITE F5 (4)------------>|
| | |<-- 18x (2) F6--| | |
| |<- 18x (2) F7 -| | | |
|<- 18x (1) F8-| | | | |
|- PRACK(1)F9->| | | | |
| |- PRACK(2)F10->| | | |
| | |- PRACK(2) F10->| | |
| | |<-- 200 F11(2)-| | |
| |<- 200 (2) F12-| | | |
|<- 200(1) F13-| | | | |
| | |<-- 18x (3) F14-------| |
| |<- 18x (3) F15-| | | |
|<UPDATE(1) F16| | | | |
|- 200 (1)F17->| | | | |
| |- PRACK(2)F18->| | | |
| | |- PRACK F4(3)F19----->| |
| | |<----200 (3) F20 -----| |
| |<- 200 (3) F21-| | | |
| | | | | |
| | |<-- 18x (4) F22-------------|
| |<- 18x (4) F23-| | | |
|<UPDATE(1) F24| | | | |
|- 200 (1)F25->| | | | |
| |- PRACK(4)F26->| | | |
| | |- PRACK F27(4)------------->|
| | |<-- 200 SDP (4)F28----------|
| |<- 200 (4) F29-| | | |
| | | | | |
| | |<-- 200 SDP (4)F26----------|
| |<- 200 (4) F27-| | | |
|<UPDATE(1) F28| | | | |
|-- 200(1)F29->| | | | |
|<- 200(1) F30-| | | | |
| | |- CANCEL F31 -->| | |
| | |<--200 F32(2)--| | |
| | |<--487 F33(2)--| | |
| | |---ACK F34(2)->| | |
| | | | | |
Jesske Expires April 30, 2015 [Page 12]
Internet-Draft forking answer correlation in B2BUA October 2014
| | |- CANCEL (3) F35 ---->| |
| | |<----200 (3) F36 -----| |
| | |<----487 (3) F37 -----| |
| | |<----ACK (3) F38 -----| |
| | | | | |
| | | | | |
|- ACK(2) F39->| | | | |
| |- ACK (4) F40->| | | |
| | |--- ACK (4) F41------------>|
Figure 3: Example Call Flow with 100rel
Call will be forked to 3 end devices. UAS_2 answers with 18x
containing a SDP and 100rel required. 18x is passed to the UAC and
made reliable with PRACK (F9-F13) Further 18x arrive at the B2BUA.
The B2BUA stores the to tag for the call context. The B2BUA will
answer the 18x and made it reliable with PRACK. The UPDATE sent in
F8 and F16 is not really needed since with arriving the F27 200OK the
finally used SDP is provided. Then the SDP negotiated between B2BUA
and UAS has to be negotiated with the F28 UPDATE sent towards the
UAC. No further activity is done towards the UAC. The B2BUA does
not need any media awareness for this procedures as long there is no
need for transcoding or other manipulation of media.
Please note that this behaviour could result in some media clipping
since the final 200 OK is delayed due to the UPDATE/200OK cycle.
Thus UA only cutting through media with 200OK may have some delay
With arriving of a 200 OK at the B2BUA from UAS_4 the B2BUA has to
construct first an UPDATE in the case that the SDP differs from the
last UPDATE sent to the UAC. The 200 OK received by the B2BUA and
trigges the final response to the UAC (F27). Editors NOTE:
Clarification needed if the UPDATE or 200OK INVITE must be sent
first.
Also all other open Call legs are canceled. F31-34 and F35-38 will
be done in parallel. Also ACK F39-F41 is done imediate after the UAC
has received the 200OK INVITE.
4.4. Forking use case with provisional responses with SDP using 100rel
and preconditions
This section describes use case where preconditions will be used.
his apply e.g. in mobile networks where resource reservation is used.
The recondition mechanism in RFC3312 [RFC3312] shows the needed
additional procedures. A B2BUA doing correlation in between to
Jesske Expires April 30, 2015 [Page 13]
Internet-Draft forking answer correlation in B2BUA October 2014
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.
Figure 4 shows the normal forking behavior when the UAC understands
the prcondition handling. The use case is handling two UAS where the
INVITE is forked to.
.
UAC Proxy Forking Proxy UAS_2 UAS_3
| | | | |
|- INVITE F1-->| | | |
| |- INVITE F2 -->|- INVITE F3(2)->| |
| | |- INVITE F4(3)------->|
| | |<-- 183 (2) F5--| |
| |<- 183 (2) F6 -| | |
|<- 183 (2) F7-| | | |
|- PRACK(2)F8->| | | |
| |- PRACK(2)F9-->| | |
| | |- PRACK(2) F10->| |
| | |<-- 200 F11(2)-| |
| |<- 200 (2) F12-| | |
|<- 200(2) F13-| | | |
|UPDATE(2)F13->| | | |
| | UPDATE(2)F14->| | |
| | |- UPDATE(2)F15->| |
| | |<-- 200 F16(2)-| |
| |<- 200 (2) F17-| | |
|<- 200(2) F18-| | | |
| | |<-- 180 (2) F19-| |
| |<- 180(2) F20 -| | |
|<- 180(2) F21-| | | |
|-PRACK(2)F22->| | | |
| |- PRACK(2)F23->| | |
| | |- PRACK(2) F24->| |
| | |<-- 200 F25(2)-| |
| |<- 200 (2) F26-| | |
|<- 200(2) F27-| | | |
| | |<-- 183 (3) F28-------|
| |<- 183 (3) F29-| | |
|<- 183 (3)F30-| | | |
|- PRACK(3)F31>| | | |
| |- PRACK(3)F32->| | |
| | |- PRACK F4(3)F33----->|
| | |<----200 (3) F34 -----|
| |<- 200 (3) F35-| | |
|<- 200(3) F36-| | | |
|UPDATE(3)F37->| | | |
Jesske Expires April 30, 2015 [Page 14]
Internet-Draft forking answer correlation in B2BUA October 2014
| | | | |
| |- UPDATE F38->| | |
| | |- UPDATE F39 ------->|
| | |<----200 (3) F40 -----|
| |<- 200 (3) F41-| | |
|<- 200(3) F42-| | | |
| | | | |
| | |<-- 200 SDP (3)F43----|
| |<- 200 (3) F44-| | |
|<--200(3)F45 -| | | |
| | |- CANCEL F47 -->| |
| | |<-- 200 F48(2)-| |
| | |<--487 (2) F49 -| |
| | |<--ACK (2) F50 -| |
|- ACK(3) F51->| | | |
| |- ACK (3) F52->| | |
| | |--- ACK (3) F53------>|
| | | | |
| | |< INVITE F54(3)-------|
| |< INVITE F55---| | |
|< INVITE F56--| | | |
|--200(3)F57 ->| | | |
| |- 200 (3) F58->| | |
| | |----200 (3) F59 ----->|
Figure 4: Example Call Flow with preconditions without B2BUA
Jesske Expires April 30, 2015 [Page 15]
Internet-Draft forking answer correlation in B2BUA October 2014
UAC supporting 100rel and preconditions
F1: INVITE SDP offer A1 (Codec A, Codec B)
F7: 183 (2) SDP answer A1 (Codec A)
F13: UPDATE (2) SDP offer A2 (Codec A) UAC resources reserved
F18: 200 OK (2) SDP Answer A2 (Codec A) UAS_2 resources reserved
F30: 183 (3) SDP answer A1 (Codec B)
F37: UPDATE (3) SDP offer A2 (Codec B) UAC resources reserved
F42: 200 OK (3) SDP answer A2 (Codec B) UAS_3 resouces reserved
F45: 200 OK (3) Final Response
F56: INVITE (3) May appear when F1 offer was set to inactive
Tis INVITE sets it to sendrecive
F57: 200 OK (3) Final Response for Re-INVITE
Figure 5 describes the use case is where the UAC sends a dialog
request with 100rel and preconditions supported/required and the
UAS_2 apply to the requested mechanisms. The B2BUA has to have media
awareness and also 3PCC capabilities.
With applying preconditions the resource reservation needs to be
finalized before 200 OK is sent. In this scenario where the SIP call
is forked and the first UAS answers with a 183 containing 100rel and
preconditions requires an the correct SDP answer to UAC, and UAS
starts its resource reservation mechanism (F5-F18). The B2BUA acts
as signalling and media-aware functionality between the Forking
Server and the UAC.
When the UAS_3 will send back also an 183 containing SDP and their
required header is set to 100rel and preconditions the B2BUA has to
reserve the resources towards the UAS (F30-F37). This use case
assumes that the leg between the UAC and B2BUA will not be updated to
avoid to many codec renegotiation and resource reservation. Thus the
B2BUA will renegotiate when the final 200 OK will arrive at the
B2BUA.
.
UAC B2BUA Forking Proxy UAS_2 UAS_3
| | | | |
|- INVITE F1-->| | | |
| |- INVITE F2 -->|- INVITE F3(2)->| |
| | |- INVITE F4(3)------->|
| | |<-- 183 (2) F5--| |
| |<- 183 (2) F6 -| | |
|<- 183 (1) F7-| | | |
Jesske Expires April 30, 2015 [Page 16]
Internet-Draft forking answer correlation in B2BUA October 2014
|- PRACK(1)F8->| | | |
| |- PRACK(2)F9-->| | |
| | |- PRACK(2) F10->| |
| | |<-- 200 F11(2)-| |
| |<- 200 (2) F12-| | |
|<- 200(1) F13-| | | |
|UPDATE(1)F13->| | | |
| | UPDATE(2)F14->| | |
| | |- UPDATE(2)F15->| |
| | |<-- 200 F16(2)-| |
| |<- 200 (2) F17-| | |
|<- 200(1) F18-| | | |
| | |<-- 180 (2) F19-| |
| |<- 180(2) F20 -| | |
|<- 180(1) F21-| | | |
|-PRACK(1)F22->| | | |
| |- PRACK(2)F23->| | |
| | |- PRACK(2) F24->| |
| | |<-- 200 F25(2)-| |
| |<- 200 (2) F26-| | |
|<- 200(1) F27-| | | |
| | |<-- 183 (3) F28-------|
| |<- 183 (3) F29-| | |
| |- PRACK(3)F30->| | |
| | |- PRACK F4(3)F31----->|
| | |<----200 (3) F32 -----|
| |<- 200 (3) F33-| | |
| | | | |
| |- UPDATE F34->| | |
| | |- UPDATE F35 ------->|
| | |<----200 (3) F36 -----|
| |<- 200 (3) F37-| | |
| | | | |
| | |<-- 200 SDP (3)F40----|
| |<- 200 (3) F41-| | |
|<- UPDATE F42-| | | |
|-- 200 F43 ->| | | |
|<- UPDATE F44-| | | |
|-- 200 F45 ->| | | |
|<-- 200 F46 -| | | |
| | |- CANCEL F47 -->| |
| | |<-- 200 F48(2)-| |
| | |<--487 (3) F49 -| |
| | |<--ACK (3) F50 -| |
|- ACK(1) F51->| | | |
| |- ACK (3) F52->| | |
| | |--- ACK (3) F53------>|
Jesske Expires April 30, 2015 [Page 17]
Internet-Draft forking answer correlation in B2BUA October 2014
Figure 5: Example Call Flow with preconditions
F1: INVITE SDP offer A1 (Codec A, Codec B)
F7: 183 SDP answer A1 (Codec A)
F13: UPDATE SDP offer A2 (Codec A) UAC resources reserved
F28: 200 OK SDP Answer A2 (Codec A) UAS resources reserved
F42: UPDATE SDP offer A3 (Codec B)
F43: 200 OK SDP Answer A3 (Codec B) UAS resouces reserved
F46: 200 OK Final Response
Where the B2BUA decides to pass 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.
Editor's Note: Question is if the above described mechanism would be
a proper mechanism since the later renegotiation + resource
reservation could cause media clipping. Figure 6 shows the other
possibility.
.
UAC B2BUA Forking Proxy UAS_2 UAS_3
| | | | |
|- INVITE F1-->| | | |
| |- INVITE F2 -->|- INVITE F3(2)->| |
| | |- INVITE F4(3)------->|
| | |<-- 183 (2) F5--| |
| |<- 183 (2) F6 -| | |
|<- 183 (1) F7-| | | |
|- PRACK(1)F8->| | | |
| |- PRACK(2)F9-->| | |
| | |- PRACK(2) F10->| |
| | |<-- 200 F11(2)-| |
| |<- 200 (2) F12-| | |
|<- 200(1) F13-| | | |
|UPDATE(1)F13->| | | |
| | UPDATE(2)F14->| | |
| | |- UPDATE(2)F15->| |
| | |<-- 200 F16(2)-| |
| |<- 200 (2) F17-| | |
|<- 200(1) F18-| | | |
| | |<-- 180 (2) F19-| |
| |<- 180(2) F20 -| | |
Jesske Expires April 30, 2015 [Page 18]
Internet-Draft forking answer correlation in B2BUA October 2014
|<- 180(1) F21-| | | |
|-PRACK(1)F22->| | | |
| |- PRACK(2)F23->| | |
| | |- PRACK(2) F24->| |
| | |<-- 200 F25(2)-| |
| |<- 200 (2) F26-| | |
|<- 200(1) F27-| | | |
| | |<-- 183 (3) F28-------|
| |<- 183 (3) F29-| | |
| |- PRACK(3)F30->| | |
| | |- PRACK F4(3)F31----->|
| | |<----200 (3) F32 -----|
| |<- 200 (3) F33-| | |
| | | | |
| |- UPDATE F34->| | |
| | |- UPDATE F35 ------->|
| | |<----200 (3) F36 -----|
| |<- 200 (3) F37-| | |
|<- UPDATE F38-| | | |
|-- 200 F39 ->| | | |
|<- UPDATE F40-| | | |
|-- 200 F41 ->| | | |
|<- UPDATE F42-| | | |
|<-- 200 F43 -| | | |
| | |<-- 200 SDP (3)F44----|
| |<- 200 (3) F45-| | |
|<-- 200 F46 -| | | |
| | |- CANCEL F47 -->| |
| | |<-- 200 F48(2)-| |
|- ACK(2) F49->| | | |
| |- ACK (4) F50->| | |
| | |--- ACK (4) F51------>|
Figure 6: Example Call Flow with preconditions
F1: INVITE SDP offer A1 (Codec A, Codec B)
F7: 183 SDP answer A1 (Codec A)
F13: UPDATE SDP offer A2 (Codec A) UAC resources reserved
F28: 200 OK SDP Answer A2 (Codec A) UAS resources reserved
F38: UPDATE SDP offer A3 (Codec B)
F39: 200 OK SDP Answer A3 (Codec B)
F40: UPDATE SDP offer A4 (Codec B) 2BUA resources reserved
F41: 200 OK SDP Answer A4 (Codec B) UAS resouces reserved
F44-46 200 OK Final Response
Jesske Expires April 30, 2015 [Page 19]
Internet-Draft forking answer correlation in B2BUA October 2014
4.5. 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 ring tone or a specific
announcement sent back.
Note: More work is needed to describe the use case.
.
UAC B2BUA Forking Proxy UAS_2 UAS_3 UAS_4
| | | | | |
|- INVITE F1-->| | | | |
| |- INVITE F2 -->|- INVITE F3(2)->| | |
| | |- INVITE F4(3)------->| |
| | |- INVITE F5 (4)------------>|
| | |<-- 18x (2) F6--| | |
| |<- 18x (2) F7 -| | | |
|<- 18x (1) F8-| | | | |
|- PRACK(1)F9->| | | | |
| |- PRACK(2)F10->| | | |
| | |- PRACK(2) F10->| | |
| | |<-- 200 F11(2)-| | |
| |<- 200 (2) F12-| | | |
|<- 200(1) F13-| | | | |
| | | | | |
| | | | | |
| early media played ( on behalf of UAS_2) | | |
|<==============================================| | |
| | |<-- 18x (3) F14-------| |
| |<- 18x (3) F15-| | | |
| | | | | |
| |- PRACK(2)F18->| | | |
| | |- PRACK F4(3)F19----->| |
| | |<----200 (3) F20 -----| |
| |<- 200 (3) F21-| | | |
| | | | | |
| | |<-- 18x (4) F22-------------|
| |<- 18x (4) F23-| | | |
| | | | | |
| |- PRACK(4)F26->| | | |
| | |- PRACK F27(4)------------->|
| | |<-- 200 SDP (4)F28----------|
| |<- 200 (4) F29-| | | |
| | | | | |
| | |<-- 200 SDP (4)F26----------|
| |<- 200 (4) F27-| | | |
| | |- CANCEL F31 -->| | |
Jesske Expires April 30, 2015 [Page 20]
Internet-Draft forking answer correlation in B2BUA October 2014
| | | | | |
|<=========disconnect early media played=======>| | |
| | | | | |
| | | | | |
| | | | | |
| | |<--200 F32(2)--| | |
| | |<--487 F33(2)--| | |
| | |---ACK F34(2)->| | |
| | | | | |
| | | | | |
|-- 200(1)F29->| | | | |
|<- 200(1) F30-| | | | |
| | | | | |
| | |- CANCEL (3) F35 ---->| |
| | |<----200 (3) F36 -----| |
| | |<----487 (3) F37 -----| |
| | |<----ACK (3) F38 -----| |
| | | | | |
| | | | | |
|- ACK(2) F39->| | | | |
| |- ACK (4) F40->| | | |
| | |--- ACK (4) F41------------>|
Figure 7: Example Call Flow with 100rel
5. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
6. Security Considerations
Currently no further security considerations are needed beyond
considerations made in the referred RFC's for SIP RFC3261 [RFC3261],
reliability of provisional responses RFC3262 [RFC3262] and resource
management RFC3312 [RFC3312].
7. Acknowledgments
The author like to thank Paul Kyzivat for his extensive review and
comments on the first draft version.The Autor would like to thank
Brett Tate, and Sergio Ibanez for their input and discussion.
Jesske Expires April 30, 2015 [Page 21]
Internet-Draft forking answer correlation in B2BUA October 2014
8. References
8.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.
[RFC6026] Sparks, R. and T. Zourzouvillys, "Correct Transaction
Handling for 2xx Responses to Session Initiation Protocol
(SIP) INVITE Requests", RFC 6026, September 2010.
[RFC6141] Camarillo, G., Holmberg, C., and Y. Gao, "Re-INVITE and
Target-Refresh Request Handling in the Session Initiation
Protocol (SIP)", RFC 6141, March 2011.
[RFC6228] Holmberg, C., "Session Initiation Protocol (SIP) Response
Code for Indication of Terminated Dialog", RFC 6228, May
2011.
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Authentication Protocol (EAP) Mutual Cryptographic
Binding", RFC 7029, October 2013.
Jesske Expires April 30, 2015 [Page 22]
Internet-Draft forking answer correlation in B2BUA October 2014
8.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. Appendix
Author's Address
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany
Phone: +4961515812766
Email: r.jesske@telekom.de
Jesske Expires April 30, 2015 [Page 23]