Subject: [Sipping] RE: I-D ACTION:draft-stucker-sipping-early-media-indirection-00.t xt

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Feb 2007 10:17:57 +0000

Brian,

Although I am interested in this general problem space and welcome
proposals, I had a hard time understanding the benefits this gives compared
to RFC 3960. For example, in section 6.2.2 it states:

"This dialog, known as an early-media dialog, allows the UAC to receive
early media from endpoints other than the called party's device(s) such as a
network media server, does not suffer from the problems of forking (since
each indirect early-media session creates a separate early media dialog),
allows for the UAC to specify a different RTP payload type (to facilitate
discrimination of early-media versus final-media), and gives both the UAC
and UAS the ability to explicitly start and stop the early media stream
without complicating the SDP negotiations for the final media."

It is not clear which of these properties of the new mechanism are not
available with RFC 3960. For example, when an INVITE request is forked, each
branch of the fork establishes a separate early dialog according to RFC
3960. Forking to a media server could either create a separate early dialog
or use a separate SDP offer-answer exchange (early session disposition)
within the context of an existing early dialog. The separate offer-answer
exchange permits things like use of a different RTP payload type or
different port. Explicitly stopping an early media stream can be done by a
further offer-answer exchange using early session disposition.

Section 6.2.3 fails to say how the proxy that instructed the UAC to play an
early media stream can subsequently tell the UAC to stop that stream
(assuming the dialog between the UAC and the media server does not pass
through that proxy).

The Early-Media header field definition does not appear to provide any
information about the nature of the early media, although the examples do
seem to show something of this nature, e.g., "service=ringback;user=userb",
but presumably this is information for the media server and not for
consumption by the UAC. The UAC will therefore not be able to determine
relative priorities of Early-Media header fields received on different early
dialogs from the same or different proxies.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 13 February 2007 20:50
> To: [email-masked]
> Subject: I-D 
> ACTION:draft-stucker-sipping-early-media-indirection-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: Early Media INDirection (EMIND) in 
> the Session Initiation Protocol (SIP)
> 	Author(s)	: B. Stucker
> 	Filename	: 
> draft-stucker-sipping-early-media-indirection-00.txt
> 	Pages		: 18
> 	Date		: 2007-2-13
> 	
>    This document describes models that can be used to manage multiple
>    early media streams in the Session Initiation Protocol (SIP).  The
>    model seeks to allow calling party endpoints to be able to better
>    control the rendering of early media to the user, and distinguish
>    early media from final media.
> 
>    Although some of early media challenges are likely to never be
>    overcome, (e.g. when interworking with an ISUP PSTN 
> gateway that does
>    not take into account CPG or ACM messages), the potential 
> to improve
>    on what is already there does exist.  The recommendations in this
>    document are intended to be an update to RFC-3960 
> recommendations and
>    to avoid many of the complications outlined in
>    draft-stucker-sipping-early-media-coping.
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-stucker-sipping-earl
> y-media-indirection-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in 
> the body of 
> the message. 
> You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then 
> "get draft-stucker-sipping-early-media-indirection-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE 
> /internet-drafts/draft-stucker-sipping-early-media-indirection
> -00.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Wed, 14 Feb 2007 17:44:12 -0600

Thanks for reading the draft John. Replies below.

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Wednesday, February 14, 2007 7:18 PM
> To: Stucker, Brian (RICH1:AR00); [email-masked]
> Subject: RE: I-D 
> ACTION:draft-stucker-sipping-early-media-indirection-00.t xt
> 
> Brian,
> 
> Although I am interested in this general problem space and 
> welcome proposals, I had a hard time understanding the 
> benefits this gives compared to RFC 3960. For example, in 
> section 6.2.2 it states:
> 
> "This dialog, known as an early-media dialog, allows the UAC 
> to receive early media from endpoints other than the called 
> party's device(s) such as a network media server, does not 
> suffer from the problems of forking (since each indirect 
> early-media session creates a separate early media dialog), 
> allows for the UAC to specify a different RTP payload type 
> (to facilitate discrimination of early-media versus 
> final-media), and gives both the UAC and UAS the ability to 
> explicitly start and stop the early media stream without 
> complicating the SDP negotiations for the final media."
> 
> It is not clear which of these properties of the new 
> mechanism are not available with RFC 3960. For example, when 
> an INVITE request is forked, each branch of the fork 
> establishes a separate early dialog according to RFC 3960. 
> Forking to a media server could either create a separate 
> early dialog or use a separate SDP offer-answer exchange 
> (early session disposition) within the context of an existing 
> early dialog. The separate offer-answer exchange permits 
> things like use of a different RTP payload type or different 
> port. Explicitly stopping an early media stream can be done 
> by a further offer-answer exchange using early session disposition.

At the last IETF, I asked attendees to raise their hands if any of them
had implemented early session disposition: nobody raised their hands,
and yet the problems of early media persist. RFC-3960 suffers from a
couple of problems that I outlined in
draft-stucker-sipping-early-media-coping. Even with early session
disposition, it's difficult to tell what's early media and what's final
media until you get a 200 OK. Even with RFC-3960 it's very difficult to
control multiple forked call legs that are generating early media (ie.
you have two or more people talking to you at once, and others that may
be sending you a 180 which further complicates things).

The proposed mechanism is to get rid of all of these problems by using a
dynamic RTP payload type (if you want to overload the RTP port at the
originator with early and final media) and simply establish a separate
session for each early media stream. This way everything is nice and
neat. You can start and stop it very clearly (INVITE/CANCEL/BYE) no
special logic is needed in the middle of the network to handle injection
of 183's with SDP for network based early media, etc, etc.

> 
> Section 6.2.3 fails to say how the proxy that instructed the 
> UAC to play an early media stream can subsequently tell the 
> UAC to stop that stream (assuming the dialog between the UAC 
> and the media server does not pass through that proxy).

Why would it? It's a proxy. Do you have a usecase? I'm sure something
could be proposed if it's necessary.

> 
> The Early-Media header field definition does not appear to 
> provide any information about the nature of the early media, 
> although the examples do seem to show something of this 
> nature, e.g., "service=ringback;user=userb", but presumably 
> this is information for the media server and not for 
> consumption by the UAC. The UAC will therefore not be able to 
> determine relative priorities of Early-Media header fields 
> received on different early dialogs from the same or 
> different proxies.

This is definitely true. This is a first revision of the proposed
mechanism to see if there's any support for this type of approach in
general. If people don't see value in setting up a separate session to
handle early media interactions, then the presence or absence of
information in the Early-Media header about prioritization is moot.

> >    overcome, (e.g. when interworking with an ISUP PSTN gateway that 
> > does
> >    not take into account CPG or ACM messages), the potential to 
> > improve
> recommendations 
> > and
> > logging in, type "cd internet-drafts" and then "get 
> > draft-stucker-sipping-early-media-indirection-00.txt".
> > 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >