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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 06 Jul 2000 10:07:08 +0300

Hi,

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

The idea is to establish a session between A and B. The presence of C
should be transparent to the user plane. So, C issues the INVITE without
waiting for A to pick up the phone. In fact, A's phone is not ringing,
since the preconditions are not met yet.

Third party control is useful not just for "telephones". A might be, for
instance, a SIP video camera and B a storage device. We do not want the
storage device to begin recording until the camera begins filming (nor
the other way around)...

Jonathan Rosenberg wrote:

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

I like better the PRACK solution than the re-INVITE approach. PARCKs
would provide a way of updating SDPs from the UAC towards the UAS. In
some situations this is very useful.

Regards,

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

---

From: [email-masked]
Date: Thu, 6 Jul 2000 12:14:08 -0600

At the risk of belaboring the point, I believe that once the preconditions
have been met in the flow illustrated earlier in the thread (i.e. COMETs
have been exchanged), C has no control over the order of operations; i.e.
whether A or B will connect to the session first. For at least some
services, telephones being one, it may make sense for C to enforce a
particular order of operations - C may want A to connect to the session
before B. If order of operations is essential to a particular service with
preconditions, then perhaps a similar flow might be constructed in which it
is guaranteed that A will provide a final response before B has the
opportunity to begin alerting.

Moreover, it is not clear to me how 3pcc SIP could guarantee the
simultaneity of final responses from A or B, regardless of preconditions,
for a service such as the camera and storage device that must connect at the
same time. Clearly, A or B simply might not be able to join the session for
reasons unrelated to qos or security. I think the best you can do is choose
one to go first - satisfaction of preconditions is not, as I understand it,
an indication that the entity in question will actually join the session.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Thursday, July 06, 2000 1:07 AM
To: Peterson, Jon
Cc: [email-masked]; [email-masked]
Subject: Re: [SIP] QoS & Third Party Call Control in SIP

Hi,

Regards,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Jul 2000 08:29:50 +0300

Hi,

[email-masked] wrote:
> whether A or B will connect to the session first.

This is true. C cannot control A or B sending 180 and after some time a
200. It is up to A or B.

> For at least some

Yes. For some services you will for sure have one party answering before
the other one is even alerted. There are so many different services you
one think of that it is imposible to define the standard behavior for
them.

> reasons unrelated to qos or security.

Yes. It might happen that the QoS requirements are fulfil but the party
does not want to join the session.

> I think the best you can do is choose

You are right, but if we think of services where one of the SIP UAs is a
machine, not a human, it will respond almost always, excep in failure
conditions, with a 200 OK. So, sometimes it might be useful not to wait
in order to speed up the set up phase.

Anyway, I agree with you that in many situations we will want to wait
until one of the parties involved has answered. But again, this should
be up to the implementors, I do not believe this is a protocol issue.

Regards,

Gonzalo