Subject: AW: AW: [Sip] PRACK holding the offer

From: Mayer Georg <[email-masked]>
Date: Thu, 14 Feb 2002 17:37:13 +0100

Hello Jonathan et al,

thanks for the answer - I have another question on this issue. As you know I work with 3G and our scenarios up till now use the manyfolks draft as the basis for SDP negotiation. I am convinced that the new solutions as proposed in the unify draft will solve our requirements too and some 3G delegates (including me) will propose a complete change of the 3G flows to the new unify solution. Still I have a question ...

With manyfolks we had a fixed three-way handshake and COMET was the indication that ressource reservation has finnished. The involved entities knew that after three SDP exchanges they are allowed to reserve ressources. 

With the new solution I do not see how both sides know when the "final" SDP answer was sent / has arrived and ressources can be reserved. In theory both sides can go on sending UPDATEs again and again. For 3G we need a very clear criteria that tells us that ressource reservation can now be done as (e.g.) SDP negotiation has now finished for the time of dialog establishment. 

I am aware that UPDATE can be sent at any time during the dialog, to change the media. But there needs to be an indication saying that for a certain change media can be reserved.

Can you please tell me how such a mechanism will be achieved with the unified procedures?

Thanks
Georg

_______________________________________________________
Georg Mayer - Siemens AG
Information and Communication Mobile
ICM N PG SP ST N 1
Hofmannstr. 51, 81359 Munich, Germany
Fon: +49-89-722-33114
Fax: +49-89-722-62250
Mobile: +49-172-5371233
Email: [email-masked]

> -----Ursprüngliche Nachricht-----
> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Mittwoch, 13. Februar 2002 21:15
> An: Mayer Georg
> Cc: Gonzalo Camarillo; Hisham Khartabil; [email-masked]
> Betreff: Re: AW: [Sip] PRACK holding the offer
> 
> 
> 
> 
> Mayer Georg wrote:
> > 
> > Hello,
> > 
> > does this mean the PRACK will generally not be allowed to carry SDP
> > information or were the comments below only based on the initially
> > described scenario (no SDP in INVITE and 183)?
> 
> No, we are only talking about the initial offer.
> 
> It is allowed for the following to occur:
> 
> inital offer in the initial INVITE
> initial answer in the 18x
> second offer in PRACK
> second answer in 2xx
> 
> Take a look at the rules about this in bis-07.
> 
> > 
> > >From 3GPP point of view it would be of great value of 
> INVITE/183 and its
> > PRACK/200 could carry SDP, follwed by COMET/200 after ressource
> > reservation.
> 
> UPDATE/COMET would also be allowed to contain offers after the initial
> exchanges have completed, yes.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 14 Feb 2002 12:10:12 -0500

Mayer Georg wrote:
> 
> Hello Jonathan et al,
> 
> thanks for the answer - I have another question on this issue. As you
> know I work with 3G and our scenarios up till now use the manyfolks
> draft as the basis for SDP negotiation. I am convinced that the new
> solutions as proposed in the unify draft will solve our requirements too
> and some 3G delegates (including me) will propose a complete change of
> the 3G flows to the new unify solution. Still I have a question ...
> 
> With manyfolks we had a fixed three-way handshake and COMET was the
> indication that ressource reservation has finnished. The involved
> entities knew that after three SDP exchanges they are allowed to reserve
> ressources.

Note that, in the current manyfolks, the final exchange is only needed
to negotiate down a codec set, for example.

> 
> With the new solution I do not see how both sides know when the "final"
> SDP answer was sent / has arrived and ressources can be reserved. In
> theory both sides can go on sending UPDATEs again and again. For 3G we
> need a very clear criteria that tells us that ressource reservation can
> now be done as (e.g.) SDP negotiation has now finished for the time of
> dialog establishment.

OK, so here is how it works with unify.

A session has state associated with it. That state is things like the
set of codecs, the ptime attributes, sendonly/recvonly, etc. UPDATE,
generally, can change these, just like INVITE can. The first step of
unify is to review reservations as just another piece of state
associated with a stream, NO DIFFERENT that the directionality. Those
states inlcude things like "no resveration", "reserved in the recv
direction", "reserved in the send direction" and "reserved in both
directions". UPDATE can update this state.

Independent of that, there is a notion of a precondition. This
precondition states that "don't ring the phone until this piece of
session state achieves this value". That precondition is expressed using
Require plus an sdp param that indicates what the desired state is. Once
the session state (in this case, the reservation) achieves the desired
value as a result of an UPDATE, the phone can ring. 

SO, the flow would be thus. A sends an INVITE to B, with an audio
stream. The reservation state is present, set to "no reservation". There
is the require header in there, and a precondition of "reservation state
= reserved in both directions". B gets this, doesn't ring the phone. It
sends a 183 w/ the answer. Its SDP also indicates that the reservation
state is unreserved. After this, both sides reserve (or, the may do
another o/a exchange in PRACK/2xx to subset of the codecs, if needed).
Once reservations complete, the state of the reservations have changed.
From A's perspective, the state is now, "reserbed in the recv
direction", so it would send an UPDATE to update that state. Once B
learns that its reservation is done (assuming rsvp style reservations
w/o confirmation), it can then ring the phone, since from its
perspective, the shared reservation state then achieves the value of
"reserved in both directions" and the precondition is met.

Note that, the requirement of the mechanism is merely that the
precondition is met; this is through local knowledge and a combination
of signaled information, as needed. It is perfectly reasonable for any
of the following to happen:

1. if reservation confirmations exist in the reservation protocol, the
callee may know through those that the reservations have completed in
both directions, and therefore it can ring the phone before receiving an
UPDATE from A, which need not even be sent.

2. the reservations may exist before the call is made. In that case, the
INVITE SDP would indicate a state of "reserved in both directions"
immmediately, with the precondition, and ringing could take place
immediately upon receipt of the INVITE.

With this model, it is also easy to fix the (IMHO big) problem of
manyfolks today, which is its strong bias towards e2e reservation. We
can have parameters for any model of reservation state, and as long as
those are defined, UPDATE can modify them. So, for example, we could
have a segmented reservation parameter, which expresses a local
reservation only. Such a parameter would have four states:

unreserved locally and remotely
reserved locally, not remotely
reserved remotely, not locally
reserved locally and remotely

you can bump that to 16 states if you want to have directional
reservations on each link. Then, the precondition is an expression of a
particular state, such as "reserved locally and remotely". So, consider
the case of access only reservations, and a case where the reservation
is done on the calling side before the call starts (note that, with
access reservations, there may not be a need to know the remote party
address before making the reservation). So, the INVITE would be like:

INVITE
reservation state = "reserved locally, not remotely"
preconditon = "reserved locally and remotely"

the callee gets this. It does its link reservation. Thus, the state is
now the desired "reserved locally and remotely". The precondition is
met. The phone rings. The following is sent in the 180:

180
reservation state= "reserved locally and remotely"

In my view, the precondition state is always represented by a value of
another existing parameter. This makes it far broader in applicability
than the currently documented mechanisms, and also allows for trivial
definition of other reservation state variables that can more readily
represent different deployments. Furthermore, the additional message
exchanges may not always be needed, depending on the specific
preconditions and the specific reservation capabilities.

Sorry for the long note, I hope that helps.

Thanks,
Jonathan R.