Subject: [Sipping] New version of the early media draft

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 10 Feb 2003 13:41:22 +0200

Folks,

I have just sumitted a new version of the early media draft. Until it
appears in the archives, you can fetch it from:

http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-media-01.txt

I have included all the (long and useful) discussions we had in the
mailing list. Therefore, the draft now keeps separate the "gateway" and
the "application server" models. I have also removed the parts we did
not agree on.

Feedback is, as usual, appreciated.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 21 Feb 2003 12:29:49 -0600

Gonzalo,
It seems the single greatest difficulty with the gateway model (as you point out in your draft) is the difficulty of depending on the arrival of media packets to determine whether or not to generate local ringing.  I have previously (last summer) suggested a solution to this (use 180 exclusively to indicate that local ringing should override any inband media and 183 otherwise) that is unacceptable since it does not satisfy the requirement that 180 be used to indicate alerting of the called party.

Have you considered using the Alert-Info header in the following way? Since the real problem is that we would like to be able to discriminate between cases when 180 should cause local ringing and when 180 should not (since inband media is available), and it is the UAS that knows conclusively which case applies, let's agree on an encoding of the Alert-Info header that indicates that local ringing should not be applied.  The following line is a syntactically valid header:

Alert-Info: <data:,>

This header identifies the Alert-Info as the null string, which seems unambiguously and efficiently interpretable within a 180 response as "do not play local ringing even though the called party is being alerted."  If the UAC does not recognize it or chooses not to interpret it for security reasons, it can be safely ignored.

This modest addition to your draft (or an equivalent mechanism) would make it unnecessary for the gateway model to depend on local policy or incoming media packet detection and is completely consistent with all of the constraints you have documented.

Another approach may be to actually specify the rtp stream as the source of the alert info (although this would require the definition of a new URI scheme type).  It might look like:

Alert-Info: <rtp:/12.34.56.78:90>

where the Alert-Info specifies the address and port of the rtp stream.  I don't like this mechanism since it is redundant with SDP and prone to error.  It is also ambiguous in the event of any subsequent media change using UPDATE (Do I begin to generate local ringing if the rtp stream source address changes?  Or do I continue to listen to the address specified in the Alert-Info and ignore any UPDATEs?  No to both.)

May I suggest including such a mechanism (preferably the first one) in your draft.

Richard Ejzak
Lucent Technologies

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]]
Sent: Monday, February 10, 2003 5:41 AM
To: sipping
Subject: [Sipping] New version of the early media draft

Folks,

Thanks,

Gonzalo

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 24 Feb 2003 15:27:59 -0800

Gonzallo, 

I finally had a chance to read the new version of early media draft. Kind of
interesting
that this version didn't get much feedback at all.

It is a very good document. I think you have captured very well the very
many issues that
were discussed last year. I am very comfortable with this new version.

I have only one suggestion (and a minor one). In section 2.2 on page 7, in
the paragraph that
starts with "Note" just below point 3, I would change the lst sentence to
the following:

   This type of gateway could choose to generate local ringback upon
reception 
   of a 180 (Ringing) response, and override or mix it with any incoming
media that 
   happens to arrive (if it does at all).

> Sent: Monday, February 10, 2003 3:41 AM
> To: sipping
> I have just sumitted a new version of the early media draft. 
> Until it appears in the archives, you can fetch it from:
> 
http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-m
edia-01.txt

I have included all the (long and useful) discussions we had in the mailing
list. Therefore, the draft now keeps separate the "gateway" and the
"application server" models. I have also removed the parts we did not agree
on.

Thanks,

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 24 Feb 2003 18:59:21 -0500

Though I didn't say so to this list, I also thought this document was a
great improvement, and I'm also very comfortable with it.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Monday, February 24, 2003 3:28 PM
To: 'Gonzalo Camarillo'; 'sipping'
Subject: RE: [Sipping] New version of the early media draft

Gonzallo, 

> From: Gonzalo Camarillo [ mailto:[email-masked]
<mailto:[email-masked]> ] 
http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-m
edia-01.txt
<http://standards.ericsson.net/gonzalo/papers/draft-camarillo-sipping-early-
media-01.txt>  

Thanks, 

Gonzalo 
<https://www1.ietf.org/mailman/listinfo/sipping>