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

From: [email-masked]
Date: Wed, 5 Jul 2000 23:21:20 -0600

I have a question about the flow below. When C has acquired the provisional
media (183) SDP from A, is that the time at which C would like to send an
INVITE to B? Or would C rather wait until someone actually picks up the
phone at A? Obviously, in a telephone-based service, if A has not yet
answered when B starts ringing, this could lead to confusion, if the service
is structured in such a way that the order of operations is important.

I would have thought that C would wait until a user had answered at A (200
OK received) before sending an INVITE to B. In this case, the held SDP
enables C to ACK the 200 OK and re-INVITE when it receives B's SDP. But
again, it may depend on the service that one is implementing.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 05, 2000 10:45 PM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]
Subject: Re: [SIP] QoS & Third Party Call Control in SIP

[email-masked] wrote:
> 
> 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).

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

> 
> 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.

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

_______________________________________________
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: Sat, 08 Jul 2000 01:36:32 -0400

> is structured in such a way that the order of operations is important.

Good observation.

Interestingly, 3pcc as you have defined (INVITE the 2nd user once the
first answers) and preconditions fundamentally contradict each other.
Preconditions says that you don't send a 200 OK until resources are
reserved; but, you can't reserve resources until you have the address of
the other party with whom you are exchanging media. Getting this address
requires C to send an INVITE to the other party, so it can get back a
183 with this information. This contradicts the type of 3pcc you desire,
where you don't want to send an INVITE to the the 2nd party until the
first answers with a 200 OK.

Note that its not sending the INVITE which you really want to avoid, but
you want to make sure one phone rings only after the other has picked
up. This, actually, can be accomplished if we make COMET symmetrical, in
the sense that the caller and called party must both send each other
COMET in order to cause ringing at the other side. WIth this, A and B
will both eventually send COMET to C (note that neither A or B are
ringing). Now, C can send a COMET to A, and then wait for A to answer
the phone (200 OK), before sending a COMET to B. This causes As phone to
ring first, and then Bs phone to ring only after A picks up, as desired.
The reverse can also be accomplished. This allows control of the
ordering of ringing even with preconditions.

This, however, is not how preconditions work now. Do people believe it
valuable to define such symmetry in order to enable this kind of 3pcc
service?

Thanks,
Jonathan R.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 10 Jul 2000 10:36:05 +0300

Hi,

> ordering of ringing even with preconditions.

This is exactly the behavior I am after.

> valuable to define such symmetry in order to enable this kind of 3pcc

It sounds like a good idea to me. The caller must have the possibility
to request COMET from the callee. The previous mode of operation (just
COMET from caller to callee) must still be available.

I believe that combining 3rd party control and QoS/security
preconditions is important. There are some services that need this
extension in order to work as it is expected.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 13 Jul 2000 17:14:54 +0300

Hi Jonathan,

I have put some call flows together and I have written a small internet
draft with them. Until it appears in the archives it can be found at:
http://www.hut.fi/~gonzalo/documents/draft-camarillo-3pcc-qos-00.txt

This way we can discuss with concrete examples.

Opinions?

Thanks,

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 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland