Subject: RE: [SIP] QoS & Third Party Call Control in SIP

From: [email-masked]
Date: Wed, 5 Jul 2000 15:49:21 -0600

My $.02:

In the case of some services, it makes sense for C to send A a 'holding' SDP
(directing c= to 0.0.0.0) in the first INVITE rather than omitting SDP
entirely. Mostly, these are services for which it is likely that A will
perceive a long hiatus between the transmission of its 200 message to C and
the receipt of an ACK (I think C could want to wait until A picks up, 200 as
opposed to 18x, before ringing B, hence the possibility of a gap here).

Now, of course, one could send a=qos preconditions in this holding SDP, but
obviously without B's SDP this will not enable A to send any resource
reservation signals. What it -does- allow is for C to send an immediate ACK
to A, and then re-INVITE A later with the qos preconditions and B's media
characteristics. This should be compatible with your flow below, in which B
has already reserved resources.

Note that this assumes that it is acceptable for A's user to pick up the
phone without any guarantee that B can be reached, or that QoS is
guaranteed. I believe that the 3pcc mechanism behaves this way in a number
of cases, and that it may not, in fact, be undesirable for certain services.
Hopefully, the service provider that controls C will offer some sort of
feedback to A's user (perhaps through a media stream announcement, or other
out-of-band means when applicable) to mitigate any dead air this mechanism
could cause.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Wednesday, July 05, 2000 6:21 AM
To: sip; [email-masked]; [email-masked]
Subject: Re: [SIP] QoS & Third Party Call Control in SIP

Hi,

Some folks have pointed out that this is a similar problem to the one
DCS was trying to solve using the double-stage INVITE. This is actually
true, but I do not like the double-stage INVITE approach.

In the following example C will be the 3rd party, and the media session
will be established between A and B:

C sends an INVITE to A without SDP (issue: how can C state that QoS will
be needed if there is not SDP in the INVITE?)

A responds with 183 with a SDP.

C sends an INVITE to B with the SDP received from A. We can specify QoS
preconditions here.

B responds with 183 with its SDP and begin performing resource
reservation in the path B->A

How can now C send B's SDP to A?? If A does not have B's SDP it cannot
perform resource reservation in the path A->B... Can we re-INVITE A at
this stage?

Thanks,

Gonzalo

Gonzalo Camarillo wrote:
> 
> Hi,
> 
> The draft "Third Party Call Control in SIP", which can be found at
> http://www.cs.columbia.edu/sip/drafts/draft-rosenberg-sip-3pcc-00.txt
> 
> outlines a method for establishing a session between two hosts that have
> signalling (SIP) relationships with a 3rd host that is not involved in
> the session.
> 
> The idea is basically to send an INVITE to A-party without SDP and then
> send the SDP coming from the B-party in the ACK.
> 
> This works fine when no QoS is needed. If preconditions must be used
> this method fails. Preconditions cannot be added to the SDP in the ACK,
> since ACKs trigger no responses.
> 
> Both parties involved in the session have to know both SDP descriptions
> in order to perform resource reservation (with RSVP, for instance).
> Then, COMET will have to be sent.
> 
> Have somebody taken this into account regarding this draft? Any ideas?
> 
> Gonzalo
> --
> Gonzalo Camarillo         Phone :  +358  9 299 33 71
> Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
> Telecom R&D               Fax   :  +358  9 299 30 52
> FIN-02420 Jorvas          Email :  [email-masked]
> Finland
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 06 Jul 2000 00:44:56 -0400

> opposed to 18x, before ringing B, hence the possibility of a gap here).

In many cases this holding approach makes sense. The new version of the
3pcc draft will contain a discussion of this issue.

> has already reserved resources.

Well, C can't send an ACK since there is no final response yet. It could
include the update SDP in the PRACK, in which case you wouldn't need to
do a re-INVITE. Its worth some discussion about whether PRACK can
contain updated SDP; this sort of combines two very different functions
into a single request (acknowledging a response and updating SDP). THen
again, we've already combined those with normal ACK, so why not PRACK..?

So, the call flow would look like:

           |   INV (held SDP w/ preconditions)    |
           | ----------------> |                  |
           |   183 SDP A       |                  |
           | <---------------- |                  |
           |     INV SDP A w/ preconditions       |
           | ------------------+----------------> |
           |     183 SDP B     |                  |
           | <-----------------+----------------- |
           |  PRACK SDP B w/ preconditions        |
           | ----------------->|                  |
           |     PRACK         |                  |
           | ------------------+----------------->|
           |     200 PRACK     |                  |
           | <-----------------|                  |
           |                   |                  |
           |     200 PRACK     |                  |
           |<------------------+------------------|
           |                   |                  |
           |   COMET           |                  |
           |<------------------|                  |
           |                   |                  |
           |     COMET         |                  |
           |<------------------+------------------|
           |                   |                  |
           |    COMET          |                  |
           |-----------------> |                  |
           |                   |                  |
           |       COMET       |                  |
           |-------------------+----------------->|
           |                   |                  |
           |                   |                  |
           |                   |                  |
           |                   |                  |
           |                   |                  |
           |                   |                  |
           |                   |                  |
           |                   |                  |
                                                  |
                               A
           C                                      B

Notice something very important here. The COMET need to be sent from the
UAS back to the UAC. Thats because for the 3pcc case, C, which is the
UAC for both INVITEs, does not have a way to know whether reservation
was successful. I think the current manyfolks drafts says that the UAC
only needs to send a COMET. We may need to rethink making this symmetric
to support this 3pcc flow.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Jul 2000 12:40:44 +0300

Hi,

> 3pcc draft will contain a discussion of this issue.

It has to be taken into account that we do not have information about
port numbers nor codecs to be used.

So, the m line defining the media stream will not contain codec or port
information.

Gonzalo