Internet DRAFT - draft-haerens-sip-3pcc
draft-haerens-sip-3pcc
SIP Working Group F. Haerens
Internet Draft Alcatel
Document: <draft-haerens-sip-3pcc-00.txt> February 2001
Category: Informational
Third Party Call Control for Resource Management
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document describes how to perform third party call control in
SIP for both a basic single-media and multi-media call when SDP
preconditions are used. This draft considers the Quality of Service
and the resource management. There are no new SIP extensions needed
to accomplish this. The mechanism outlined is illustrated with
examples in order to help understand it.
2. Conventions used in this document
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 [1].
This document refers to ôcontrollerö as the entity in the third
party call control which allows to set up and manage a
communications relationship between two or more other parties [6].
3. Basic SingleûMedia Third party call control with SDP preconditions
The section explains the basic single-media third party call control
with SDP preconditions based on reference [3] W. Marshall et al,
"Integration of Resource Management and SIP", draft-manyfolks-sip-
resource-01.txt, IETF; June 2000. Work in progress.
Haerens Category:Informational û Expiration:August 2001 1
Third Party Call Control for Resource Management February 2001
The confirmation of the SDP preconditions follows the revised
procedures given in section 6.
Figure 1 presents a high-level overview of a basic Third Party Call
Control flow. This example is appropriate for a single-media
session with a mandatory quality-of-service "sendrecv" precondition,
where both the user A and User B can only perform a single-direction
("send") resource reservation.
The controller prepares for User A an SDP message body for the
INVITE describing the desired QoS and security preconditions for
each media flow, and the desired direction "sendrecv. This SDP is
included in the INVITE message sent to User A through the proxies,
and includes an entry "a=qos:mandatory sendrecv." The User A on
receipt of the INVITE , being willing to perform the requested
precondition, returns a 183-Session-Progress provisional response
containing SDP, along with the qos/security attribute for each
stream having a precondition. This 183-Session-Progress provisional
response is sent using the reliability mechanism of [2]. The
controller sends the appropriate PRACK and the User A UAS responds
with a 200-OK to the PRACK.
Figure 1 (Proposal 1)
User A User B
| Controller |
| | |
| (1) INVITE SDP held | |
|<----------------------| |
| (2) 183 w/SDP A | |
|---------------------->| |
| | (5) INVITE w/SDP A |
| (3) PRACK |---------------------->|
|<----------------------|(6) 183 w/SDP B confirm:recv
| (4) 200 OK (of PRACK) |<----------------------|
|---------------------->| (7) PRACK |
| |---------------------->|
| | (8)200 OK (of PRACK) |
| |<----------------------|
|(9) NOTIFY w/SDP B confirm:recv |
|<----------------------| |
|(10) 200 OK (of NOTIFY)| |
|---------------------->| |
| | |
| | |
| Reservation Reservation |
===========> <===========
| |
| (20) COMET | |
|---------------------->| |
| | (21) COMET |
| |---------------------->|
Haerens 2
Third Party Call Control for Resource Management February 2001
| | (22) 200 OK (of COMET)|
| |<----------------------|
| (23) 200 OK (of COMET)| |
|<----------------------| |
| |
|
|
| Controller User Alerted
| | |
| (25) 180 Ringing | (24) 180 Ringing |
|---------------------->|<----------------------|
| (26) PRACK | (27) PRACK |
|<----------------------|---------------------->|
| (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)|
|---------------------->|<----------------------|
| |
| |
| User Picks-Up
| Controller the phone
| | |
| (31) 200 OK | (30) 200 OK |
|---------------------->|<----------------------|
| | |
| (32) ACK | (33) ACK |
|<----------------------|---------------------->|
| |
Figure 1(Proposal 1): Basic 3PCC Flow with SDP Preconditions
Figure 1 (Proposal 2)
User A User B
| Controller |
| | |
| (1) INVITE SDP held | |
|<----------------------| |
| (2) 200 SDP A | |
|---------------------->| |
| (3) ACK | |
|<----------------------| |
| | (5) INVITE w/SDP A |
| |---------------------->|
| | (6) 183 w/SDP B |
| |<----------------------|
| | (7) PRACK |
| |---------------------->|
| | (8)200 OK (of PRACK) |
| (9) INVITE w/SDP B |<----------------------|
|<----------------------| |
| | |
| Reservation Reservation |
Haerens 3
Third Party Call Control for Resource Management February 2001
===========> <===========
| |
| (20) COMET | |
|---------------------->| |
| | (21) COMET |
| |---------------------->|
| | (22) 200 OK (of COMET)|
| |<----------------------|
| (23) 200 OK (of COMET)| |
|<----------------------| |
| |
|
|
| Controller User Alerted
| | |
| (25) 180 Ringing | (24) 180 Ringing |
|---------------------->|<----------------------|
| (26) PRACK | (27) PRACK |
|<----------------------|---------------------->|
| (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)|
|---------------------->|<----------------------|
| |
| |
| User Picks-Up
| Controller the phone
| | |
| (31) 200 OK | (30) 200 OK |
|---------------------->|<----------------------|
| | |
| (32) ACK | (33) ACK |
|<----------------------|---------------------->|
| |
Figure 1(Proposal 2): Basic 3PCC Flow with SDP Preconditions
Figure 1 (Proposal 3)
User A User B
| Controller |
| | |
| (1) INVITE SDP held | |
|<----------------------| (4) INVITE SDP held |
| (2) 200 SDP A |---------------------->|
|---------------------->| (5) 200 SDP B |
| (3) ACK |<----------------------|
|<----------------------| (6) ACK |
| |---------------------->|
| | (5) INVITE w/SDP A |
| |---------------------->|
| (9) INVITE w/SDP B | |
|<----------------------| |
Haerens 4
Third Party Call Control for Resource Management February 2001
| | |
| Reservation Reservation |
===========> <===========
| |
| (20) COMET | |
|---------------------->| |
| | (21) COMET |
| |---------------------->|
| | (22) 200 OK (of COMET)|
| |<----------------------|
| (23) 200 OK (of COMET)| |
|<----------------------| |
| |
|
|
| Controller User Alerted
| | |
| (25) 180 Ringing | (24) 180 Ringing |
|---------------------->|<----------------------|
| (26) PRACK | (27) PRACK |
|<----------------------|---------------------->|
| (29) 200 OK (of PRACK)| (28) 200 OK (of PRACK)|
|---------------------->|<----------------------|
| |
| |
| User Picks-Up
| Controller the phone
| | |
| (31) 200 OK | (30) 200 OK |
|---------------------->|<----------------------|
| | |
| (32) ACK | (33) ACK |
|<----------------------|---------------------->|
| |
Figure 1(Proposal 3): Basic 3PCC Flow with SDP Preconditions
Similarly the controller also prepares for User B an SDP message
body for the INVITE describing the desired QoS and security
preconditions for each media flow as received from User A into the
183-Session_Progress provisional response, and the desired direction
"sendrecv. This SDP is included in the INVITE message sent to User B
through the proxies, and includes an entry "a=qos:mandatory
sendrecv." The User B on receipt of the INVITE , being willing to
perform the requested precondition,, returns a 183-Session-Progress
provisional response containing SDP, along with the qos/security
attribute for each stream having a precondition. Since the
"sendrecv" direction tag required a cooperative effort of the User A
and User B, the User B requests a confirmation when the
preconditions are met, with the SDP entry "a=qos:mandatory sendrecv
confirm recvö. The direction-tag indicates that the COMET will be
sent by the party (here Controller) who received the confirmation-
Haerens 5
Third Party Call Control for Resource Management February 2001
tag. This 183-Session-Progress provisional response is sent using
the reliability mechanism of [2]. The controller sends the
appropriate PRACK and the User B UAS responds with a 200-OK to the
PRACK. The User B now attempts to reserve the qos resources and
establish the security associations.
The controller now waits until the receipt of the 200-OK to the
PRACK from User B is obtained before sending the SDP B to User A.
During the discussion at the 49th IETF San Diego meeting it was not
recommended to sent the SDP B into the PRACK message due to time
outs which may occur during the provisional response reliability
procedures at both sides. It was recommended to consider a re-INVITE
w/SDP B but this assumes that an 200 OK was returned for User A.
Presently a re-INVITE cannot be sent before a 200 OK is received
from the UAS. Also the sending of the initial INVITE with ôSDP
heldö may not cause an alerting to be sent to the User A (by
assuming that the sending with SDP with ôSDP heldö may not trigger
an alerting at the UserÆs A side or specifying a SDP attribute).
This procedure is given in figure 1 (proposal 2). The proposal 3
also describes the possibility that an INVITE with ôSDP heldö is
sent to user B.
In figure 1 of proposal 1 the SDP B is sent from the Controller to
the User A in a NOTIFY mechanism defined in Event Notification in
SIP [7] followed by a 200 OK message returned form Party A to the
Controller. In particular the following should be noted:
i) The NOTIFY should reflect the To:, From:, and Call-ID headers
from the INVITE as if they had arrived in a SUBSCRIBE.
ii) Analogous to the case for SUBSCRIBE described in [7], the
agent that issued the INVITE MUST be prepared to receive a NOTIFY
before the session completes.
iii) The presence of the ôAllow-Eventsö header in a message is
sufficient to indicate support for NOTIFY.
iv) The presence an ôeventö header containing e.g.Event:
precondition is proposed
As an alternative solution the INFO mechanism or the 18x-Session-
Progess message using the reliability mechanism could be considered.
The use of the 18x-Session-Progress message is not recommended
because this assumes that call progress messages need to be sent
from UAC to UAS, it should also be decided whether a new 18x-
Session-Progress or the present 183-Session-Progress could be used.
It is proposed that a decision is made on one of the above
proposals.
Haerens 6
Third Party Call Control for Resource Management February 2001
The figures 1 above describe the various proposals for passing the
SDP B on receipt in the controller of the 200-OK to the PRACK from
User B.
The SDP B will be sent to the User A with the SDP entry as received
from User B with the qos attribute set to "a=qos:mandatory sendrecv
confirm recvö. The direction-flag will indicate that the COMET
message will be sent by the party (here User A) who received the
confirmation-tag. The SDP B is received by the User A, and the User
A requests the resources needed in its "send" direction, and
establishes the security associations. Once the preconditions are
met, the User A sends a COMET message as requested by the
confirmation token. This COMET message contains an entry
"a=qos:success send". This COMET message is relayed by the
controller via a COMET message to User B.
At this point the User A is also alerted and a 180- Ringing
provisional response is forwarded. This provisional response is
also sent using the reliability mechanism of [2], resulting in a
PRACK message and 200-OK of the PRACK
The User B successfully performs its resource reservation, in its
"send" direction, and waits for the COMET message from the User A.
On receipt of the COMET message, the User B combines the "send"
confirmation in the SDP with its "send" success, and knows all
preconditions have been met. The User B then continues with session
establishment. At this point it alerts the user, and sends a 180-
Ringing provisional response. This provisional response is also
sent using the reliability mechanism of [2], resulting in a PRACK
message and 200-OK of the PRACK.
When the User A or User B answers, the normal SIP 200-OK final
response is sent through the proxies to the Controller; and the
controller responds with an ACK message.
At this point, both users A and B are in a single point-to-point
call and are under control of a third party (named controller)
provided the controller has identified itself in the From field of
the INVITE. It should be noted that the media is exchanged between
users A and B rather than with the controller.
Either user can terminate the call. An endpoint that detects an
"on-hook" (request to terminate the call) releases the QoS resources
held for the connection, and sends a SIP BYE message to the
controller which still has complete control over the call. This
message will be acknowledged with a 200-OK.
4. Message example of a Basic SingleûMedia Third party call control
with SDP preconditions
In this example the controller is part of a gateway which e.g. maps
the Open Service Access interface method from the Application
Servers to the SIP based Service Capability Servers.
Haerens 7
Third Party Call Control for Resource Management February 2001
See also section 6 for more details on the use of the proposed third
party call control flows for the OSA architecture.
(1)
INVITE sip:userA@provider1.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
Require: 100rel
From: Controller <sip:Controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
Contact: Controller<sip:controller@gateway.provider3.com>
Content-Type: application/sdp
Content-Length: 156
v=0
o=Controller 2891234526 2891234526 IN IP gateway.provider3.com
s=Session SDP
c=IN IP4 0.0.0.0
t=0 0
m=audio 0 RTP/AVP
a=qos:mandatory sendrecv
(2)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP gateway.provider3.com:5060
Require: 100rel
RSeq: 223344
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
Contact: UserA <sip:userA@provider1.com>
Content-Type: application/sdp
Content-Length: 169
v=0
o=UserA 2891234526 2891234526 IN IP4 provider1.com
s=Session SDP
c=IN IP4 10.0.0.3
t=0 0
m=audio 30002 RTP/AVP 0 8
a=qos:mandatory sendrecv
(3)
PRACK sip:userA@provider1.com SIP/2.0
RAck: 223344 1 INVITE
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:Controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 2 PRACK
Haerens 8
Third Party Call Control for Resource Management February 2001
(4)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 2 PRACK
(5)
INVITE sip:UserB@provider2.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
Require: 100rel
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com>
Call-ID: 11223344@gateway.provider3.com
CSeq: 1 INVITE
Contact: Controller <sip:controller@gateway.provider1.com>
Content-Type: application/sdp
Content-Length: 268
v=0
o=Controller 2891234526 2891234526 IN IP4 gateway.provider3.com
s=Session SDP
t=0 0
m=audio 30002 RTP/AVP 0 8
c=IN IP4 10.0.0.3
a=qos:mandatory sendrecv
The INVITE method to User B could also be sent using the same Call-
ID (= 12345678)as the INVITE to User A and will create a second call
leg. This INVITE message must contain a ôbranch=1ö field in order to
distinguish the various/repeated responses received from the
different call legs involved.
INVITE sip:UserB@provider2.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060; branch=1
Require: 100rel
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com>
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
Contact: Controller <sip:controller@gateway.provider1.com>
Content-Type: application/sdp
Content-Length: 268
v=0
o=Controller 2891234526 2891234526 IN IP4 gateway.provider3.com
s=Session SDP
t=0 0
m=audio 30002 RTP/AVP 0 8
c=IN IP4 10.0.0.3
a=qos:mandatory sendrecv
Haerens 9
Third Party Call Control for Resource Management February 2001
(6)
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP gateway.provider3.com:5060
Require: 100rel
RSeq: 334455
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:userB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 1 INVITE
Contact: UserB <sip:userB@provider2.com>
Content-Type: application/sdp
Content-Length: 246
v=0
o=UserB 2891234526 2891234526 IN IP4 provider2.com
s=Session SDP
c=IN IP4 10.0.0.2
t=0 0
m=audio 40002 RTP/AVP 8
a=qos:mandatory sendrecv confirm recv.
(7)
PRACK sip:UserB@provider2.com SIP/2.0
RAck: 334455 1 INVITE
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 2 PRACK
(8)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 2 PRACK
(9)
SIP/2.0 NOTIFY
Via: SIP/2.0/UDP gateway.provider3.com:5060
Require: 100rel
RSeq: 445566
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
Contact: UserA <sip:userA@provider1.com>
Content-Type: application/sdp
Haerens 10
Third Party Call Control for Resource Management February 2001
Content-Length: 169
v=0
o=UserB 2891234526 2891234526 IN IP4 provider2.com
s=Session SDP
c=IN IP4 10.0.0.2
t=0 0
m=audio 40002 RTP/AVP 8
a=qos:mandatory sendrecv confirm recv
(10)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 3 PRACK
(20)
COMET sip:UserA@provider1.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
To: UserA <sip:UserA@provider1.com>
From: Controller <sip:controller@gateway.provider3.com>
;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 COMET
Content-Type: application/sdp
Content-Length: 159
v=0
o=UserA 2891234526 2891234526 IN IP4 userA.provider1.com
s=Session SDP
c=IN IP4 10.0.0.3
t=0 0
m=audio 30002 RTP/AVP 0 8
a=qos:success sendrecv
(21)
COMET sip:UserB@provider2.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
;tag=112233
To: UserB <sip:UserB@provider2.com>
Call-ID: 11223344@gateway.provider3.com
CSeq: 3 COMET
Content-Type: application/sdp
Content-Length: 248
v=0
o=UserA 2891234526 2891234526 IN IP4 userA.provider1.com
s=Session SDP
t=0 0
Haerens 11
Third Party Call Control for Resource Management February 2001
m=audio 30002 RTP/AVP 0 8
c=IN IP4 10.0.0.3
a=qos:success sendrecv
(22)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
;tag=112233
To: UserB <sip:UserB@provider2.com>
Call-ID: 11223344@gateway.provider3.com
CSeq: 3 COMET
(23)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
To: UserA <sip:UserA@provider1.com>
From: Controller <sip:controller@gateway.provider3.com>
;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 COMET
(24)
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 1 INVITE
(25)
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:UserA@provider1.com> ;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
(26)
PRACK sip:userA@provider1.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:Controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 2 PRACK
RAck: 223344 1 INVITE
(27)
Haerens 12
Third Party Call Control for Resource Management February 2001
PRACK sip:UserB@provider2.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 2 PRACK
RAck: 334455 1 INVITE
(28)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 2 PRACK
(29)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:userA@provider1.com>;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 2 PRACK
(30)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:UserB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 1 INVITE
Contact: UserB <sip:userB@provider2.com>
Content-Type: application/sdp
Content-Length: 178
v=0
o=UserB 2891234526 2891234526 IN IP4 userB.provider2.com
s=Session SDP
c=IN IP4 10.0.0.2
t=0 0
m=audio 40002 RTP/AVP 8
(31)
SIP/2.0 200 OK
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:UserA@provider1.com> ;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 INVITE
Contact: UserB <sip:userB@provider2.com>
Content-Type: application/sdp
Haerens 13
Third Party Call Control for Resource Management February 2001
Content-Length: 178
v=0
o=UserB 2891234526 2891234526 IN IP4 userB.provider2.com
s=Session SDP
c=IN IP4 10.0.0.2
t=0 0
m=audio 40002 RTP/AVP 8
(32)
ACK sip:userA@provider1.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserA <sip:UserA@provider1.com> ;tag=123456
Call-ID: 12345678@gateway.provider3.com
CSeq: 1 ACK
(33)
ACK sip:userB@provider2.com SIP/2.0
Via: SIP/2.0/UDP gateway.provider3.com:5060
From: Controller <sip:controller@gateway.provider3.com>
To: UserB <sip:userB@provider2.com> ;tag=112233
Call-ID: 11223344@gateway.provider3.com
CSeq: 1 ACK
5. Multi-Media Third party call control with SDP preconditions
The section explains the multi-media third party call control with
SDP preconditions based on reference [3] W. Marshall et al,
"Integration of Resource Management and SIP", draft-manyfolks-sip-
resource-01.txt, IETF; June 2000. Work in progress.
Figure 2 presents a high-level overview of an advanced end-point to
end-point (User A-User B) third party call flow. This example is
appropriate for a multiple-media session with some combination of
mandatory and optional quality-of-service precondition. For
example, the User A may suggest five media streams, and be willing
to establish the session if any three of them are satisfied.
The use of reliable provisional responses is assumed.
The controller prepares for UserA an SDP message body for the INVITE
describing the desired QoS and security preconditions for each media
flow, and the desired direction "sendrecvö. This SDP is included in
the INVITE message sent to UserA through the proxies, and includes
an entry "a=qos:mandatory sendrecv.or an entry "a=qos:optional
sendrecv.ö as appropriate " The UserA on receipt of the INVITE ,
being willing to perform the requested precondition, returns a 183-
Session-Progress provisional response containing SDP, along with the
qos/security attribute for each stream having a precondition and the
desired direction.. The User A also requests confirmation of the
Haerens 14
Third Party Call Control for Resource Management February 2001
preconditions with the relevant direction-tag. This 183-Session-
Progress provisional response is sent using the reliability
mechanism of [2]. The controller sends the appropriate PRACK and
the UserA UAS responds with a 200-OK to the PRACK.
Similarly the controller also prepares for UserB an SDP message body
for the INVITE describing the desired QoS and security preconditions
for each media flow as received from UserA into the 183-
Session_Progress provisional response, and the desired direction
"sendrecvö. This SDP is included in the INVITE message sent to
UserB through the proxies, and includes an entry "a=qos:mandatory
sendrecv." or an entry "a=qos:optional sendrecv.ö as appropriate
together with the relevant confirmation of the preconditions and
direction tags.
The UserB on receipt of the INVITE , prepares an SDP message body
for the INVITE describing the desired QoS and security preconditions
for each media flow, and the desired directions being willing to
perform the requested precondition, returns a 183-Session-Progress
provisional response containing SDP. Since the "sendrecv" direction
tag required a cooperative effort of the UserA and UserB, the UserB
requests a confirmation when the preconditions are met, with the SDP
entry "a=qos:mandatory sendrecv or an entry "a=qos:optional
sendrecv.ö as appropriate together with the required confirmation of
the preconditions and direction tags.
This 183-Session-Progress provisional response is sent using the
reliability mechanism of [2]. The controller sends the appropriate
PRACK and the UserB UAS responds with a 200-OK to the PRACK. The
UserB now attempts to reserve the qos resources and establish the
security associations.
The controller now waits until the receipt of the 200-OK to the
PRACK from User B is obtained before sending the SDP B to User A.
When the 200-OK is received in the controller the SDP B is sent to
the User A in a NOTIFY mechanism defined in Event Notification in
SIP [7] followed by a 200 OK message returned form Party A to the
Controller.
When the User B has completed the resource reservations and security
session establishment, it sends a confirmation to the User A relayed
by the Controller in the form of a COMET message, with each
precondition marked in the SDP as either success or failure. Note
that if User B was not satisfied with the combination of successful
preconditions, it could instead have responded with 580-
Precondition-Failure, and ended the INVITE transaction.
If the User A has satisfied its preconditions, and is satisfied with
the preconditions achieved by the User B, it responds with the COMET
message. The COMET message is relayed via the Controller and
contains the SDP with the success/failure results of each
precondition attempted by User A. If User A is not satisfied with
Haerens 15
Third Party Call Control for Resource Management February 2001
the combination of successful preconditions, it could instead have
sent a CANCEL message.. Otherwise, the session proceeds as in the
previous example.
On receipt of the COMET message which is relayed via the
controller, the User B examines the combination of satisfied
preconditions reported by User A, and makes a final decision whether
to proceed with the session. If sufficient preconditions are not
satisfied, the User B responds with 580-Precondition-Failure.
Otherwise, the session proceeds as in the previous example.
User A User B
| Controller |
| | |
| (1) INVITE SDP held | |
|<----------------------| |
| (2) 183 w/SDP A | |
|---------------------->| |
| | (5) INVITE w/SDP A |
| (3) PRACK |---------------------->|
|<----------------------| (6) 183 w/SDP B |
| (4) 200 OK (of PRACK) |<----------------------|
|---------------------->| (7) PRACK |
| |---------------------->|
| | (8)200 OK (of PRACK) |
| (9) NOTIFY |<----------------------|
|<----------------------| |
|(10) 200 OK (of NOTIFY)| |
|---------------------->| |
| | |
| Reservation Reservation |
===========> <===========
| |
| | (20) COMET |
| (21) COMET |<----------------------|
|<----------------------| |
| (22) 200 OK (of COMET)| |
|---------------------->| (23) 200 OK (of COMET)|
| |---------------------->|
| |
| (24) COMET | |
|---------------------->| (25) COMET |
| |---------------------->|
| | (26) 200 OK (of COMET)|
|(27) 200 OK (of COMET) |<----------------------|
|<----------------------| |
| |
|
| Controller User Alerted
| | |
| (29) 180 Ringing | (28) 180 Ringing |
|---------------------->|<----------------------|
Haerens 16
Third Party Call Control for Resource Management February 2001
| (30) PRACK | (31) PRACK |
|<----------------------|---------------------->|
| (33) 200 OK (of PRACK)| (32) 200 OK (of PRACK)|
|---------------------->|<----------------------|
| |
| |
| User Picks-Up
| Controller the phone
| | |
| (35) 200 OK | (34) 200 OK |
|---------------------->|<----------------------|
| | |
| (36) ACK | (37) ACK |
|<----------------------|---------------------->|
| |
Figure 2: 3PCC Flow with negotiation of optional preconditions
6. Enhancements required to the COMET Method
6.1 Justification for extensions to the COMET Method
In the Third Party call establishment the behavior of the Originator
(UCA) and the Destination (UAS) for handling the requested
confirmation of a precondition has to be extended as discussed at
the San Diego 49th IETF meeting (see Ref. {5]).
With regard to the examples given in sections 3, 4 and 5 the
following should be noted:
i)If in the Basic single-media third party call control example the
mandatory precondition is to be confirmed from User A to the
controller then this has to be requested via an INVITE method with
the ôconfirmö attribute present. This is presently specified in
reference [2].If subsequently this mandatory precondition is to be
indicated (confirmed) from the Controller to the User B then this
has to be requested by the controller via a ôconfirmö attribute
present in a method forwarded from controller to User B.(from the
calling party to the called party). The COMET from the calling party
(controller) to the called party B can only be indicated
(triggered)if e.g. a ôconfirmö attribute is included in the INVITE.
This is presently not supported in reference [2].
ii)A similar reasoning can be done for the multi-media third party
call control in order to request the sending of COMETÆs for the
directions Controller to User A triggered by the controller.
The conclusion is that the COMET method procedures specifying the
behavior have to be extended for the sending of COMETs from the
calling party to the called party triggered by the calling party at
the Originating side and for the sending of COMETs from the called
party to the calling party triggered by the called party at the
Destination side.
Haerens 17
Third Party Call Control for Resource Management February 2001
It was proposed at the San Diego meeting to define the qos-attribute
as follows:
qos-attribute = "a=qos:" strength-tag SP direction-tag
[SP confirmation-tag]
strength-tag = ("mandatory" | "optional" | "success" |
"failure")
direction-tag = ("send" | "recv" | "sendrecv")
confirmation-tag = "confirm" SP direction-tag
The direction-tag of the confirmation-tag indicates which party
sends the COMET message.
i) If a direction-tag ôsendö is included in the confirmation-tag
then the send party will confirm the COMET message.
ii) If a direction-tag ôrecvö is included then the party who
received the confirmation-tag will confirm the COMET message.
iii) If a direction-tag ôsendrecvö is included then the send and
receive party of the confirmation-tag will confirm the COMET
message.
The definition of the allowed values for the direction attribute in
the response are as follows:
The following table illustrates the allowed values for the direction
attribute in the response. Each row represents a value of the
direction in the SIP INVITE, and each column the value in the
response. An entry of N/A means that this combination is not
allowed. A value of A->B (B->A) implies that the COMET will be sent
from A to B (B to A). A value of A<->B means that the will be two
COMETs, one in each direction. The value in the response is the one.
used by both parties.
B: response
A: request send recv sendrecv none
send N/A A->B A<->B N/A
recv B->A N/A A<->B N/A
sendrecv N/A N/A A<->B N/A
none B->A A->B A<->B No COMETs
6.2 Revised SIP Usage Rules for the COMET method procedures
This section is provided as a place holder and will contain the
revised SIP Usage Rules of section 8 in reference {3} for the
enhancements explained under section 6.1 based on the agreements of
the 50th IETF Minneapolis Meeting. Both the procedures for Basic and
Third Party call control will be described.
6.2.1. Overview
The session originator (UAC) prepares an SDP message body for the
INVITE describing the desired QoS and security preconditions for
Haerens 18
Third Party Call Control for Resource Management February 2001
each media flow, and the desired directions. The token value "send"
means the direction of media from originator (whichever entity
created the SDP) to recipient (whichever entity received the SDP in
a SIP message), and "recv" is from recipient to originator. In an
INVITE, the UAC is the originator, and the UAS is the recipient. The
roles are reversed in the response.
Note: This description is given as an initial proposal for further
refinement.
For Third Party Call control the following figure 3 gives an example
of how the confirm direction flags could be applied.
User A User B
| Controller |
| | |
| (1) INVITE SDP held a:qos.mandatory.sendrecv |
|<----------------------| |
| | |
| Receive Send | |
O<======================O |
| Send Receive | |
O======================>O |
| |
| |
| (2) 183 w/SDP A conf:send |
|---------------------->| |
| |(5) INVITE w/SDP A conf:send
| |---------------------->|
| | Send Receive |
| |======================>O
| | Receive Send |
| O<======================O
| (3) PRACK | |
|<----------------------|(6)183 w/SDP B conf:send
| (4) 200 OK (of PRACK) |<----------------------|
|---------------------->| (7) PRACK |
| |---------------------->|
| | (8)200 OK (of PRACK) |
| |<----------------------|
| | |
|(9) NOTIFY w/SDP B conf:send |
|<----------------------| |
|(10) 200 OK (of NOTIFY)| |
|---------------------->| |
| | |
| Reservation Reservation |
===========> <===========
| |(20) COMET success:Sendrecv
| |<----------------------|
|(21) COMET success:Sendrecv |
|<----------------------| |
Haerens 19
Third Party Call Control for Resource Management February 2001
| (22) 200 OK (of COMET)| |
|---------------------->| (23) 200 OK (of COMET)|
| |---------------------->|
| |
|(24) COMET success:Sendrecv |
|---------------------->|(25) COMET success:Sendrecv
| |---------------------->|
| | (26) 200 OK (of COMET)|
|(27) 200 OK (of COMET) |<----------------------|
|<----------------------| |
| |
The recipient of the INVITE (UAS) returns a 18x provisional response
containing a Content-Disposition of "precondition," and SDP with the
qos/security attribute for each stream having a precondition. The
UAS would typically include a confirmation with a direction value
(either send or recv or sendrecv) requesting whether the sender
should confirm both directions (sendrecv) or only one direction
(either send or recv). The SDP is a subset of the preconditions
indicated in the INVITE. Unlike normal SIP processing, the UAS MUST
NOT alert the called user at this point. The UAS now attempts to
reserve the qos resources and establish the security associations.
The 18x provisional response is received by the UAC. If the 18x
contained SDP with mandatory qos/security parameters, the UAC does
not let the session proceed until the mandatory preconditions are
met. The UAC attempts to reserve the needed resources and establish
the security associations.
If either party requests a confirmation, a COMET message is sent to
that party. The COMET message contains the success/failure
indication for each precondition. For a precondition with a
direction value of "sendrecv," the COMET indicates whether the
sender is able to confirm both directions or only one direction.
Upon receipt of the COMET message, the UAC/UAS continues normal SIP
call handling, by (for a UAS) alerting the user and sending e.g. a
180-Ringing or 200-OK response. The UAC SIP transaction completes
normally.
7. Applicability of the Third Party call control procedures.
7.1 Use in the Open Service Access Architecture
<Text to be provided for this section>
7.2 QoS enabled and assured control establishment.
<Text to be provided for this section>
Haerens 20
Third Party Call Control for Resource Management February 2001
8. Security Considerations
If the contents of the SDP contained in the 183-Session-Progress are
private then end-to-end encryption of the message body can be used
to prevent unauthorized access to the content.
The security considerations given in the SIP specification apply to
the COMET method. No additional security considerations specific to
the COMET method are necessary.
9. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2] J. Rosenberg and H. Schulzrinne, "Reliability of provisional
responses in SIP," Internet Draft, Internet Engineering Task Force,
July 2000. Work in progress.
[3] W. Marshall et al, "Integration of Resource Management and SIP",
draft-manyfolks-sip-resource-01.txt, IETF; June 2000. Work in
progress.
[4] M. Handley/H. Schulzrinne/E. Schooler/J. Rosenberg, "SIP:
Session Initiation Protocol", RFC 2543, IETF; Mach 1999.
[5] G. Camarillo, "Third party call control with SDP preconditions",
draft-camarillo-3pcc-qos-00.txt, IETF; July 2000. Work in progress.
[6] J. Rosenberg/J. Peterson/H. Schulzrinne/Camarillo, "Third Party
Call Control in SIP", draft-rosenberg-sip-3pcc-01.txt, IETF; May
2001. Work in progress.
[7] Roach, A., ôEvent Notification in SIPö draft-roach-sip-
subscribe-notify-02, November 2000.
10. Acknowledgments
The author would like to recognize the comments received from Tom
Batsele and Johan Dries from Alcatel Bell.
11. Author's Addresses
Frans Haerens
Alcatel Bell
Francis Welles Plein, 1
B-2080 Antwerp
Belgium
Phone: +32 3 240 9034
Email: frans.haerens@alcatel.be
Haerens 21
Third Party Call Control for Resource Management February 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into
Haerens 22
