Internet DRAFT - draft-camarillo-manyfolks-confirm
draft-camarillo-manyfolks-confirm
Internet Engineering Task Force Gonzalo Camarillo
Internet draft Ericsson
October 2000
Expires June 2001
<draft-camarillo-manyfolks-confirm-00.txt>
Confirmation of SDP preconditions
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This document describes certain functionality that is missing in the
current "Integration of Resource Management and SIP" [1] (a.k.a.
manyfolks draft). An extension to add this functionality is
outlined.
This functionality is needed in general to provide richer signalling
capabilities and can be employed in several scenarios. This draft
describes its use in third party call control applications.
If this extension is accepted it is foreseen that this draft would
be merged with [1].
1. Introduction
"Integration of Resource Management in SIP" [1] provides a mechanism
that allows a UA issuing a SIP message with SDP preconditions to ask
the other party to confirm that the preconditions are met. The
"confirm" attribute together with the COMET method are used for that
purpose.
A typical situation where the "confirm" attribute is used is a two
party session with QoS preconditions. The callee will request a
Camarillo 1
Confirmation of SDP preconditions
confirmation message (COMET) from the caller by including a
"confirm" attribute in a 183 response. As soon as the calleeÆs UA
has finished the resource reservation in the callee-caller direction
(using RSVP for instance) and a COMET arrives from the caller
(confirming that resources are also available in the caller-callee
direction) the callee will be alerted.
The "confirm" attribute in (b) triggers the COMET in (e).
Caller Callee
| (a) INVITE |
|------------------>|
| (b) 183 |
|<------------------|
| (c) PRACK |
|------------------>|
|(d) 200 OK (PRACK) |
|<------------------|
| (e) COMET |
|------------------>|
| (f) 200 OK (COMET)|
|<------------------|
|(g) 200 OK (INVITE)|
|<------------------|
| (h) ACK |
|------------------>|
(a)
INVITE sip:callee@ws4321.provider2.com SIP/2.0
Via: SIP/2.0/UDP ws1234.provider1.com:5060
Require: 100rel
From: Caller <sip:caller@provider1.com>
To: Calee <sip:callee@provider2.com>
Call-ID: 12345678@ws1234.provider1.com
CSeq: 1 INVITE
Contact: Caller <sip:caller@ws1234.provider1.com>
Content-Type: application/sdp
Content-Length: 155
v=0
o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com
s=Session SDP
c=IN IP4 10.0.0.1
t=0 0
m=audio 20002 RTP/AVP 0
a=qos:mandatory sendrecv
(b)
SIP/2.0 183 Session Progress
Camarillo 2
Confirmation of SDP preconditions
Via: SIP/2.0/UDP ws1234.provider1.com:5060
Require: 100rel
RSeq: 112233
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 1 INVITE
Contact: Callee <sip:callee@ws4321.provider2.com>
Content-Type: application/sdp
Content-Length: 163
v=0
o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com
s=Session SDP
c=IN IP4 10.0.0.3
t=0 0
m=audio 30000 RTP/AVP 0
a=qos:mandatory sendrecv confirm
(c)
PRACK sip:callee@ws4321.provider2.com SIP/2.0
RAck: 112233 1 INVITE
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 2 PRACK
(d)
SIP/2.0 200 OK
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 2 PRACK
(e)
COMET sip:callee@ws4321.provider2.com SIP/2.0
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 3 COMET
Content-Type: application/sdp
Content-Length: 149
v=0
o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com
s=Session SDP
c=IN IP4 10.0.0.1
t=0 0
m=audio 20002 RTP/AVP 0
a=qos:success send
Camarillo 3
Confirmation of SDP preconditions
(f)
SIP/2.0 200 OK
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 3 COMET
(g)
SIP/2.0 200 OK
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 1 INVITE
Contact: Callee <sip:callee@ws4321.provider3.com>
Content-Type: application/sdp
Content-Length: 129
v=0
o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com
s=Session SDP
c=IN IP4 10.0.0.3
t=0 0
m=audio 30000 RTP/AVP 0
(h)
ACK sip:callee@ws4321.provider2.com SIP/2.0
Via: SIP/2.0/UDP ws1234.provider1.com:5060
From: Caller <sip:caller@provider1.com>
To: Callee <sip:callee@provider2.com> ;tag=314159
Call-ID: 12345678@ws1234.provider1.com
CSeq: 1 ACK
Contact: Caller <sip:caller@ws1234.provider1.com>
2. Caller triggering COMETs
Note that in the previous example, the COMET in (e) is sent because
the callee wanted it to be sent - (b) contained a "confirm"
parameter. If the caller included a "confirm" attribute in the
INVITE (a), it would trigger a COMET from the callee to the caller.
The caller does not have a means for triggering COMETs from the
caller to the callee. Similarly, the callee cannot trigger COMETs
from the callee to the caller.
This mechanism is needed is certain situations, such as the ones
described in [2]. The need of this mechanism is described in the
"open issues" section of [2] and it was presented in the SIP WG
meeting in Pittsburgh [3].
Camarillo 4
Confirmation of SDP preconditions
When third party call control is performed, the controller wants to
be sure that the session establishment does not go on until it sends
a COMET. The following example, taken from [2], helps understand
this need.
Controller A B
| (1) INVITE | |
|------------------>| |
| (2) 183 SDP A | |
|<------------------| |
| (3) INVITE SDP A | |
|------------------------------------->|
| (4) 183 SDP B | |
|<-------------------------------------|
| (5) PRACK SDP B | |
|------------------>| |
| (6) 200 OK (PRACK)| |
|<------------------| |
| (7) PRACK | |
|------------------------------------->|
| (8) 200 OK (PRACK)| |
|<-------------------------------------|
| (9) COMET | |
|<-------------------------------------|
|(10) 200 OK (COMET)| |
|------------------------------------->|
| (11) COMET | |
|<------------------| |
|(12) 200 OK (COMET)| |
|------------------>| |
| (13) COMET | |
|------------------>| |
|(14) 200 OK (COMET)| |
|<------------------| |
|(15) 200 OK (INVITE) |
|<------------------| |
| (16) COMET | |
|------------------------------------->|
|(17) 200 OK (COMET)| |
|<-------------------------------------|
|(18) 200 OK (INVITE) |
|<-------------------------------------|
| (19) ACK | |
|------------------>| |
| (20) ACK | |
|------------------------------------->|
| | |
Controller A B
Camarillo 5
Confirmation of SDP preconditions
After (12), all the preconditions are met. However, the controller
does not send a COMET to B (16) until A has answered the INVITE
(15). Therefore, if A relied on mechanisms different than COMET
(such as ResvConf in RSVP) to check if the resource reservation was
already done third party call control mechanisms would fail, since A
would go on with the session establishment after (12), instead of
waiting for (15). Preconditions met confirmations must rely solely
on application layer mechanisms - SIP.
Thus, a mechanism that allows the controller to ask A to wait for
the COMET before continuing with the session is needed.
3. Solution
A direction attribute is needed in order to indicate to which
direction the "confirm" attribute applies. That is, which party
sends the COMET.
Section 4 of [1] would look 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 SDP contained in INVITE (a) would look as follows:
v=0
o=Caller 2891234526 2891234526 IN IP4 ws1234.provider1.com
s=Session SDP
c=IN IP4 10.0.0.1
t=0 0
m=audio 20002 RTP/AVP 0
a=qos:mandatory sendrecv confirm send
The SDP in (b) would be then:
v=0
o=Callee 2891234526 2891234526 IN IP4 ws4321.provider2.com
s=Session SDP
c=IN IP4 10.0.0.3
t=0 0
m=audio 30000 RTP/AVP 0
a=qos:mandatory sendrecv confirm recv
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
Camarillo 6
Confirmation of SDP preconditions
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
This table assumes that the preconditions suggested in the INVITE
(e.g. mandatory sendrecv) are accepted and thus included in the
response. If the response does not include all of them (e.g.
mandatory recv) there are interactions with the direction attribute
regarding COMETs and this table would not be valid. Some N/A entries
would become valid combinations. These interactions are already
present in the current approach [1].
4. Backward compatibility
An implementation that does not understand the direction attribute
introduced by this draft would find the "a=qos" line malformed and
it will thus return an error to the UA issuing the INVITE. The UA
can then fall back to the previous syntax (defined by [1]) if it
wishes to proceed anyway.
5. References
[1] W. Marshall et al, "Integration of Resource Management and SIP",
draft-manyfolks-sip-resource-01.txt, IETF; June 2000. Work in
progress.
[2] G. Camarillo, "Third party call control with SDP preconditions",
draft-camarillo-3pcc-qos-00.txt, IETF; July 2000. Work in progress.
[3] http://www.softarmor.com/sipwg/meets/IETF48/slides/pres-
camarillo-3pccprecon-sip-48.ppt
6. Author's Addresses
Gonzalo Camarillo
Ericsson
Advanced Signalling Research Lab.
FIN-02420 Jorvas
Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com
Camarillo 7
