Subject: [Sip] Comments on "unify" draft

From: Rohan Mahy <[email-masked]>
Date: Thu, 17 Jan 2002 17:55:57 -0800 (PST)

Hi,

Below are some comments in no particluar order on:

http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt

1) Page 17  2nd paragraph discusses the benefit of communicating progress
of a forked request from each UAS all the way back to the UAC.  There are
potentially serious privacy concerns here.  I would like to see these
addressed.  Specifically, it should be none of the UACs business if one of
the branches returns a 486 Busy Here.

2) It may seem obvious, but it would be nice to mention that this proposal
only solves the HERFP problem for dialogs initiated with INVITE.  you may
want to summarize the proposed solution for other dialog initiating
methods (ban forking for that method or define a method for returning the
equivalent of 155).

3) Page 26 2nd to last para: should clarify that Content-Dispo
preconditions would have to be replaced with Require: preconditions

4) In Figure 12 on modifying codecs (could also apply to declining or
switching ports for forked early media), I see no reason why the new
offer/answer can't get sent on the PRACK/200 instead of a separate
COMET/200.  In fact, this meets all the requirements for a general
offer/answer model given on Page 16 of the draft.  You could also take
advantage of *answers* in PRACKs to speed up 3pcc flows.

5) I don't like reusing the COMET method name.  I like "UPDATE" because it
updates session state, and it can't confuse UAs that support manyfolks.

5) I'm a bit unclear on the proxy behavior proposed for 155.  If all UAs
supported 155 we wouldn't need to do anything special on a proxy.
However, what do we if one of the UASs doesn't support 155.  It would
return a 420.  Is the proxy required to do anything new with this?  I
could imagine a proxy packaging the response up and sending back to the
UAC as a 155, but then the dialog state is out of sync. Perhaps the proxy
should send 4xx errors back to the UAC in a COMET (er.. UPDATE!) message?

6) I think correlating offers and answers could get really ugly unless we
come up with a simpler correlation mechanism (especially if
intermediaries (like ALGs or B2BUAs) are involved.
I propose that we add two parameters to the SDP MIME type:

sdp-params = ( offer | answer )

offer = "offer" EQUAL sequence-number
answer = "answer" EQUAL tag

so a complex offer/asnwer dialog might look like this:

application/sdp;offer=1			first offer for this dialog
application/sdp;offer=1;answer=7839748  answer from 7839748 for this offer
...;offer=1;answer=093412	different answer from another UAS
...;offer=2			a new offer
...;offer=2;answer=093412	answer for this offer

etc...

comments/flames welcome

thanks,
-rohan

_______________________________________________
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: Mon, 21 Jan 2002 11:33:49 -0500

> http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt

Thanks for the comments.

In general, it would be helpful to get general feedback of the form 
"seems like the right direction". Particularly, the main thing I need 
feedback on ASAP is the proposal to pretty much keep this all out of 
bis. The only thing in bis would be some generalized statement of when 
you can see offers and answers, so that we can separate the 
EM/manyfolks/herfp solutions from bis. Granted, this stuff still needs 
to be on the fast track for 3g, but I want to get it separated from bis.

> the branches returns a 486 Busy Here.

The draft doesn't preclude sending a 486 busy. But, the UAS doesn't know 
if that response will be received or not by the UAC. It depends on 
whether there was a forking proxy or not in front of it. I guess I don't 
see the issue (at least, it has nothing to do with herfp).

> methods (ban forking for that method or define a method for returning

Good point. I think it works fine for other methods as well. SUBSCRIBE, 
for example. You can send it to update credentials for a forked SUBSCRIBE.

> preconditions would have to be replaced with Require: preconditions

Its not that are replaced; manyfolks still needed the Require mechanism, 
and that aspect hasn't changed.

> advantage of *answers* in PRACKs to speed up 3pcc flows.

Well, here is the reason. Because of glare, there needs to be a way to 
allow for an offer to be rejected. That is, if A and B send a COMET to 
each other at the same time, there needs to be a way for that SDP to be 
rejected in one of the COMETs. Now, I can do that for PRACK as well 
(reject it in the case of glare). But, because of the atomicity of 
request processing, this means that the provisional response thats being 
acknowledged will continue to get retransmitted, and thats bad. Its an 
artifact of accomplishing two totally different things with the same method.

Perhaps this is not deemed serious enough to worry about, and that we 
can tolerate the extra retransmits that would occur if it happens. But, 
people should be aware.

> updates session state, and it can't confuse UAs that support manyfolks.

I don't care what the name is, but I do care that it be the same 
mechanism in manyfolks as in early media as in the HERFP problem, with 
whatever name you like. I chose COMET since it seemed partly possible to 
maintain a semblance of backwards compatibility with existing 
implementations (although I must ask - are there any?).

> supported 155 we wouldn't need to do anything special on a proxy.

For the proxies not involved in the forking service, there is no change 
- 155 is propagated upstream as normal.

> return a 420.  Is the proxy required to do anything new with this? 

Yes. I would need to resubmit the request to the UAS w/o the Require 
header (it does that with a new branch). Thus, you would fallback to 
current behavior. I forgot to point this out, thanks.

> I
> UAC as a 155, but then the dialog state is out of sync.

I had thought about that. Robert and I explicitly discussed it, and we 
decided to not put that in this draft at the moment. It might work for a 
few selected responses.

 Perhaps the
> proxy

Egads....

> ...;offer=2;answer=093412	answer for this offer

Somethng like that is beginning to look like a good idea. Not sure 
exactly the right way to structure it. We can come up with that later. 
The main question to ask is whether or not bad things will happen with 
3pcc? i.e., do we ever have cases where the controller turns an answer 
into an offer, and vice a versa? Need to work through those.

-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