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

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 17 Jan 2002 14:38:38 -0500

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: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Jan 2002 12:19:04 -0800

Jonathan,

I had a look at the licensing term that you are proposing to use, and
the advice I got was the language is overly broad and cumbersome, and
implicates more than just what is in this spec. The problem is that the
phrase "any patent or other intellectual property right" is not
qualified by a scope, such as "for the implementation of this standard."
What about patents or other IPR that is not necessary for implementing
SIP, e.g. patents on graphical displays, speech recognition algorithms,
even speech compression algorithms? 

-- Christian Huitema

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 11:39 AM
> To: [email-masked]; Jonathan Rosenberg
> Subject: [Sip] solving early media, HERFP, and unifying manyfolks
> 
> Folks,
>

---

From: "Sanjoy Sen"<[email-masked]>
Date: Thu, 31 Jan 2002 15:03:21 -0600

Comments inline.

> Sent: Wednesday, January 30, 2002 11:27 AM
> To: Sen, Sanjoy [NGC:B692:EXCH]
> 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?
> 
Actually using a header such as Reason will probably be cheaper for parsing.

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

Yes, but there would a problem with general PSTN interworking. When the MGC
receives an ACM/Alerting message, it has no way to definitively infer
whether the PSTN would generate early media (e.g., remote Ring-back or
announcement). So, on receipt of ACM, the MGC may send an 180 (as you said)
to the SIP phone which starts playing local ringing (by local implementation
choice), but then any early media which might be coming through the gateway
will be lost (the EM flow can start anytime after the ACM is issued). I was
wondering what kind of rules do we need to specify to solve this issue and
whether its at all solvable by rules alone.

Sanjoy