[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/