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

From: Rohan Mahy <[email-masked]>
Date: Wed, 30 Jan 2002 14:47:02 -0800

Hi,

Here are the requirements Jonathan listed in "unify":

The general rule for offers and answers would then be the 
following:

o A UA cannot send an offer when it has sent a previous offer 
to which it has not yet gotten an answer.

o A UA cannot send an offer when it has received an offer to  
which it has not generated an answer.

o A UA can only send an offer in a message that is sent 
reliably.

o The answer to an offer has to occur in a message which is  
correlated to the message the offer came in.

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

One side effect of allowing an offer/answer in any message 
matching the 4 requirements, is that you could (for example) 
put media on hold when sending a REFER.

INV (offer1) ->
<- 200 (answer1)
ACK ->
...
REFER (offer2) ->
a=inactive:
<- 202 (answer2)
                 triggered INVITE ->
                 etc... 

- You would definitely need to leave this decision to each 
new method (probably doesn't make sense in a SUBSCRIBE for 
example ;-).

- Since PRACK is defined in bis, PRACK would need to define 
if it is OK.  (I think it should be allowed in PRACK).

thanks,
-rohan

---- Original message ----
>Date: Wed, 30 Jan 2002 15:33:52 -0600
>From: Alan Johnston <[email-masked]>  
>Subject: RE: [Sip] solving early media, HERFP, and unifying 
manyfolks  
>To: "'Jonathan Rosenberg'" 
<[email-masked]>, "'Sanjoy Sen'" 
<[email-masked]>
>Cc: [email-masked]
>
>Jonathan,
>
>I'd like to try to focus the discussion on the issue of the 
moment
>(literally) relating to bis.
>
>While more discussion is needed before we can reach 
consensus on your
>proposal, we need to agree right now if we want to make the 
one change
>to bis to allow the possibility of this proposal.
>
>Right now, bis says that a 200 OK MUST have SDP, either an 
answer if the
>INVITE had an offer, or an offer if the INVITE did not, in 
which case
>the answer will be in the ACK.
>
>We would need to change bis to allow for the offer/answer to 
take place
>outside of the INVITE/200/ACK exchange in an extension to 
SIP.  
>
>I think it would be good to make this change, keeping the 
existing
>offer/answer model but adding a statement that extensions 
may define new
>ways of making offers or answers which could take the place 
of the bis
>discussion.  Perhaps this change is needed even for 
manyfolks COMET not
>to contradict bis?
>
>Can we come to consensus on the list to agree to this change?
>
>Thanks,
>Alan Johnston
>WorldCom
>sip:[email-masked]
>
>Jonathan Rosenberg wrote:
>
>> Sent: Wednesday, January 30, 2002 11:27 AM
>> To: Sanjoy Sen
>> Cc: [email-masked]
>> Subject: Re: [Sip] solving early media, HERFP, and 
unifying manyfolks
>> 
>> 
>> 
>> 
>> Sanjoy Sen wrote:
>> > 
>> > Hi,
>> > 
>> > Following are some of the comments on the unify draft:
>> > 
>> > 1) The draft proposes a Reason header to carry the 
reason codes. 
>> > There's also a sipfrag approach of carrying the an 
entire SIP 
>> > request/response as a new Mime type. Should there be a 
>> single approach 
>> > and if they must be different, what're the pros and cons 
of their 
>> > usage?
>> 
>> I was going for the simplest thing, since there seemed 
littl 
>> ebenefit to encapsulation as opposed to just including the 
>> headers and bodies within the provisional response, as 
needed.
>> 
>> Is there a concrete reason why encapsulation is better?
>> 
>> > 
>> > 2) Its not clear how the UA determines when to stop 
local 
>> ringing and 
>> > await early media. Pre-bis05 drafts mentioned using SDP 
>> within 183 to 
>> > indicate this to the UA. Does the UAC wait for a 1) new 
>> Offer, or 2) 
>> > an Answer, to stop any local ringing that might be 
taking place. I 
>> > guess the behavior would be same as for regular media, 
but it would 
>> > help if this is clarified.
>> 
>> There is no difference between early media and media. 
Local 
>> alerting would presumably take place as a local 
>> implementation choice once a suitable provisional response 
>> (180, typically) has been received to indicate that the 
far 
>> end is, in fact, ringing. It would continue until the 
>> establishment of the session, early or otherwise. As a 
>> result, a 183 w/SDP finalizes the establishment of the 
>> session, and so that would stop any local ringback. 
>> 
>> I suppose that suspension of the session, with port zero, 
>> before the dialog is completed, would be a way to signal a 
>> UAC to revert back to local ringback, if that 
functionality 
>> was needed.
>> 
>> 
>> > 
>> > 3) We support Rohan's proposal of using the new method 
>> UPDATE instead 
>> > of reusing the COMET, as the semantics are significantly 
different 
>> > than COMET.
>> 
>> Seems to be a general consensus; I'd still like to hear 
from 
>> Bill on this topic in particular.
>> 
>> > 
>> > 4) Another concern is, from 3GPP perspective, if this 
draft is the 
>> > replacement of manyfolks, then that calls for some major 
changes 
>> > within the 3GPP specs. I do not support inclusion of 
this 
>> in the bis, 
>> > but the bis should discuss these issues and refer to 
this 
>> draft as the 
>> > solution & this draft should be progressed towards the 
last 
>> call ASAP.
>> 
>> I see little gain in having bis reference this document, 
that 
>> will introduce an unneeded dependency. 
>> 
>> I do agree that all of this, plus the recent route stuff, 
is 
>> going to be a lot of editing work for the folks 
maintaining 
>> 24.228. I certainly appreciate their work and patience in 
our 
>> struggle to get everything aligned and working for them.
>> 
>> -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

_______________________________________________
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 01:28:37 -0500

> put media on hold when sending a REFER.

Well, I guess, although I must admit I hadn't thought about it.

> new method (probably doesn't make sense in a SUBSCRIBE for

Right, agreed. Bis would need to say that.

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