Subject: Re: [Sip] solving early media, HERFP, and unifying manyfolks

From: Rohan Mahy <[email-masked]>
Date: Thu, 31 Jan 2002 11:52:23 -0800

I think I am missing something....

>Rohan Mahy wrote:
>> The general rule for offers and answers would then be the
>> following:
>> 
>> 1) A UA cannot send an offer when it has sent a previous 
offer
>> to which it has not yet gotten an answer.
>> 
>> 2) A UA cannot send an offer when it has received an offer 
to
>> which it has not generated an answer.
>> 
>> 3) A UA can only send an offer in a message that is sent
>> reliably.
>> 
>> 4) The answer to an offer has to occur in a message which 
is
>> correlated to the message the offer came in.
>> 
>> 5) If an offer does not take place in the first reliable
>> message from UAC to UAS, it must be present in a reliable
>> message from UAS to UAC.

>> - Since PRACK is defined in bis, PRACK would need to define
>> if it is OK.  (I think it should be allowed in PRACK).
>
>We need to discuss that further. Unify indicated that the 
preference was
>not to allow it in PRACK. I sent a note to the list already 
describing
>the reason. The reason is that you may need to reject an 
offer if it
>occurs in the middle of an outstanding offer (i.e., glare 
prevention).
>This means that if A sends a COMET to B with an offer, and B 
sends a
>PRACK to a previous 1xx with an offer to A, A will need to 
reject the
>PRACK for glare prevention. 

Would it help to add an additional restriction:  Don't send a 
new offer if you are still waiting for acknowledgement of a 
message you sent in the same dialog.

A would be forbidden to send an offer in a COMET (or a 200 
for the original INVITE) until its provisionals where 
acknowledged.

I think sending offers/answers in PRACK is even more useful 
in the 3pcc early media case.

basically I prefer this:

INVITE (no SDP) -->
<-- 18x (offer1)
PRACK (answer1) -->
<-- 200 (PRACK)
<-- 200 (INVITE)
ACK -->

to this:

INVITE (no SDP) -->
<-- 18x (offer1)
PRACK -->
<-- 200 (PRACK)
COMET (answer1) -->
<-- 200 (COMET)
<-- 200 (INVITE)
ACK -->

(which is technically forbidden by rule 4 above)

thanks,
-rohan

>Since all requests are processed atomically
>(that has been unstated till now, formally stated in bis-
06), that means
>that rejecting the PRACK means you effectively never got the 
PRACK, and
>thus retransmissions of the 1xx will continue. 
>
>We don't thave the same problem for 2xx/ACK, since the glare 
prevention
>is at the broader level of the entire INVITE transaction. 
That is, you
>can't even send an INVITE w/o SDP (no offer) if you have 
received an
>INVITE with SDP. 
>
>Now, maybe this point on PRACK is minor, but it is a 
concrete technical
>reason why NOT to. I welcome concrete technical reasons why 
we should,
>to compare them to find the right tradeoff.
>
>-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

_______________________________________________
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, 31 Jan 2002 15:57:03 -0500

Rohan Mahy wrote:

> message you sent in the same dialog.

It would help, yes. Its broader than you need. I am trying to think if
there would be an negative impacts from this restriction. None I can
think of off hand, though.

> for the original INVITE) until its provisionals where

As a specific instance of your rule, yes. We could also make it simpler,
which is that you can't send an offer in UPDATE (I think we have
consensus to call it UPDATE) if you have a reliable provisional response
outstanding.

> (which is technically forbidden by rule 4 above)

Right, the benefit is the savings of a transaction.

OK, I'll bite. I think the 3g guys would prefer this as well, since I
suspect the case of 1-of-N codecs + manyfolks will be a common one.
There, without sending SDP in PRACK, you'd need to to this:

INVITE (SDP offer w/ many codecs + inactive + precon) ------>
<----- 183 (SDP answer w/ one codec + inactive + precon)-----
PRACK------>
<----200 PRACK
COMET (SDP offer w/ one codec + sendrecv + precon) ----------->
<-------200 COMET (SDP answer w/ one codec + sendrecv + precon)
<-----resource reservation-------->
COMET (SDP offer w/ one codec + sendercv + conditions met)------->
<-------------200 COMET (SDP answer w/ one codec + sendrecv + conditions
met)
<---------180-------------------------------------------------
PRACK--------------------->
<-------------200 PRACK----
<-----------200
-----ACK>

This is an extra pair of messages (an extra COMET) that is not currently
in the flows in 24.228 which would need to be added. Whilst it *doesn't*
increase call setup latency, it uses more bw on the air interface. Yeah,
compression will help some, but I bet theyd prefer to avoid another
transaction to an already overly complex setup flow. Of course, I think
its even easier to avoid preconditions altogether, but let us not
discuss that.

So, let me ask for consensus on allowing the o/a exchanges in PRACK in
addition to UPDATE, subject to some kind of constraint to avoid the
problem I mention of glare on the PRACK.

Thanks,
Jonathan R.

dynamicsoft                             East Hanover, NJ 07936