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

From: "Sanjoy Sen"<[email-masked]>
Date: Mon, 28 Jan 2002 11:11:35 -0600

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?

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.

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. 

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. 

Regards,
Sanjoy 

================================
Carrier VoIP Group
Nortel Networks
Ph: 972-685-8274 (ESN: 445), Fax: 972-685-3813
Mobile: 972-571-2062

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 1:39 PM
> To: [email-masked]; Jonathan Rosenberg
> Subject: [Sip] solving early media, HERFP, and unifying manyfolks
> 
> 
> Folks,
> 
> I've been working on some of the open issues in bis, mainly 
> HERFP, the 
> usage of a three-way SDP exchange, overlapping INVITE, and 
> unification 
> of O/A with manyfolks. In the process, I came up with a joint 
> solution 
> to all of these problems. I have written it up, along with call flows 
> showing how it is used in all cases, in an I-D that I have just 
> submitted. Until that I-D appears, you may pick it up at:
> 
> http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt
> 
> In summary, the draft proposes that COMET take on a new, much broader 
> definition, encompassing the semantics of UPDATE, and then 
> some, as has 
> been discussed on the list. The draft postulates how manyfolks can be 
> recast to fit within the offer/answer model, and then shows how COMET 
> can also be used to update not just session parameters, but 
> other state, 
> in an effort to resolve HERFP. For those confused about what 
> HERFP is, 
> it is a rather nasty forking problem that interferes with 
> services, it 
> is discussed in detail in the above draft.
> 
> The proposal would change bis in a simple way, which is to generalize 
> the conditions under which SDP could appear in SIP. THis 
> generalization 
> would imply the current behavior (INV/200 or 200/ACK) for baseline 
> implementations, but would support richer exchanges for those 
> supporting 
> the new COMET. Furthermore, the draft proposes that manyfolks be 
> sufficiently generalized to provide this new form of COMET.
> 
> I would also like to point out that dynamicsoft may have IPR against 
> this draft. I will say, honestly, that we have been forced into the 
> corner of making IPR claims against IETF documents due to the 
> existence 
> of claims against IETF documents that have been made by 
> others. However, 
> our aim is ONLY defensive. As such, I have worked with our 
> attorneys to 
> work out licensing terms which I think everyone will find most 
> agreeable, and indeed, laudable. They are:
> 
> 
> 
> 
> dynamicsoft may seek patent protection on technology described in
> documents which dynamicsoft submits for use in IETF standards
> discussions.  In relation to any IETF standard incorporating any such
> technology, dynamicsoft will grant a royalty free 
> non-exclusive license 
> to Qualified Parties to utilize such technology if necessary for 
> practice of IETF standards implemented as a result of dynamicsoft's 
> submission.  As used herein, Qualified Parties means a party who has 
> not, does not and will not assert, in litigation or 
> otherwise, including 
> in licensing discussions, any patent or other intellectual property 
> right against dynamicsoft.  Any such license to a Qualified 
> Party shall 
> terminate at once if such party asserts a patent or other 
> intellectual 
> property right against dynamicsoft.  dynamicsoft will grant 
> non-exclusive licenses to Non-Qualified Parties on reasonable, 
> reciprocal non-discriminatory terms and conditions.
> 
> 
> These terms will also appear shortly on the IPR claims page 
> at the IETF 
> site. A summary of these terms is basically "leave us alone, 
> and this is 
> free". We feel that this is very much in the spirit of the IETF 
> practices and attitudes towards IPR, but recognizes that 
> companies have 
> a need to protect themselves. I would encourage others who 
> have IPR to 
> make their IPR available under similar terms, so we can focus on 
> technology work rather than acting as amateur lawyers.
> 
> Comments and questions welcome, as always.
> 
> -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: Wed, 30 Jan 2002 12:26:48 -0500

Sanjoy Sen wrote:
> 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.

> reusing the COMET, as the semantics are significantly different than

Seems to be a general consensus; I'd still like to hear from Bill on
this topic in particular.

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 30 Jan 2002 15:33:52 -0600

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,
> > 
> > 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.
> 
> > 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.
> 
> > 
> > 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.
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments on the 
> application of sip
>