Subject: [SIP] 3pcc open issue with manyfolks draft

From: William Marshall <[email-masked]>
Date: Thu, 1 Feb 2001 17:34:22 -0500 (EST)

In San Diego, third party call control was brought up again as an issue
with the manyfolks draft.  I believe it is covered by the draft as it 
exists today, and offer the following call flow to demonstrate this.

A is attempting to call B.  Proxy in the middle, CC, decides that
a transcoder, T, is needed in the call.  Resulting call is A<->T
and T<->B, with CC being the 3rd party controller of T<->B.
T is assumed to not need to ring, and it will respond immediately
with a 200-OK when the INVITE preconditions are satisfied.

In all cases below, item n+1 in a grouping is enabled by item n.
Where independent sequences start, a note indicates where the first
item in the group overlaps with the previous.

There is no question that this call flow is complex, and has lots
of messages with the third party call controller.  However, it
has the very nice property that each endpoint follows exactly the
same resource reservation procedures whether there is a 3pcc involved
or not.  All of the special handling is done by CC.

Bill Marshall
[email-masked]

1. A --INVITE-> CC				   a=qos: required sendrecv
2.		CC ---INVITE--> T		   a=qos: required sr confirm
3.		CC <----183---- T		   a=qos: required sr confirm
4. A <---183--- CC
5. A ====RSVP=================> T
6. A --COMET--> CC				   a=qos: success send
		note that CC used a Record-Route in the 183 to force the
		PRACK and COMET to go through CC.  This is independent of
		the use of a Record-Route in the 200-OK for future signaling.

(also in response to the 183 message (4) above)
5. A --PRACK--> CC ---PRACK---> T
6. A <===RSVP================== T
7.		CC <--COMET---- T		   a=qos: success send
	note that T is now stalled, waiting for CC
		to send a COMET to T.

(also in response to the INVITE message (1) above)
2.		CC ---INVITE--> T		   w/o SDP
3.		CC <----183---- T		   a=qos: required sr confirm
4.		CC -----------------INVITE----> B  a=qos: required sr confirm
5.		CC <------------------183------ B  a=qos: required sr confirm
6.		CC ------------------PRACK----> B
7.				T <===RSVP===== B
8.		CC <----COMET------------------ B  a=qos: success send
	note that B is now stalled, waiting for CC to send a COMET to B

(also in response to the 183 message (3) immediately above)
4.		CC ---PRACK---> T		   a=qos: required sr confirm
5.		CC		T ====RSVP====> B
6.		CC <--COMET---- T		   a=qos: success send

At this point, CC knows that resources are available from A->T, from T->A,
from T->B, and B->T.  It is "safe" to let the call proceed.

7.		CC ---COMET-------------------> B  a=qos: success send
8.		CC <---180--------------------- B
(CC generates a 180 response for the A<->T call, knowing that T doesn't ring)
9. A <---180--- CC
10		CC <---200--------------------- B
11		CC ---COMET---> T		   a=qos: success send
12		CC <---200----- T
13 A <---200--- CC			completes call from A<->T
(also in response to the 200-OK from B, received in (10) above)
11		CC ----200----> T	completes call from T<->B

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: "Mark Watson" <[email-masked]>
Date: Fri, 9 Feb 2001 14:18:14 -0000

Bill, all,

I think that independently of the 3rd party Call Control cases, there are
still two open issues with the manyfolks draft even for a simple two-party
case.

1) Whilst it is possible for A to require that a COMET be set in the B --> A
direction, and for B to require that a COMET be sent in the A --> B
direction, it is not possible for A to require that B awaits the A --> B
COMET or for B to require that A awaits the B --> A COMET.

If, say, A is responsible for resource reservation in both directions (send
and recv), it is quite likely that A will require B to await the A->B COMET
before alerting the user. We shouldn't be making assumptions about who is
responsible for the resource reservation - it depends on the technology
being used in the network.

2) The draft only covers pre-conditions associated with a particular media
stream - the qos is a media attribute. So, if the UA does not choose to
support that media stream, it does not wait for the COMET. I believe we
could easily extend to cope with pre-conditions which are not related to a
particular media path between the UAs (e.g. completion of some dialogue with
another network on the other side of the SIP UA.) This could be achieved by
allowing the qos attribute to appear as a session attribute.

Regards,

Mark Watson
Nortel Networks

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: 01 February 2001 22:34
> To: [email-masked]
> Subject: [SIP] 3pcc open issue with manyfolks draft
> 
>