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

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Feb 2007 12:08:53 +0000

Brian,

See below.

John 

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: 14 February 2007 23:44
> To: Elwell, John; [email-masked]
> Subject: RE: I-D 
> ACTION:draft-stucker-sipping-early-media-indirection-00.txt
> 
> Thanks for reading the draft John. Replies below.
> 
> > -----Original Message-----
> > 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.
[JRE] The reason it hasn't been implemented is perhaps its complexity or
perceived complexity, but I don't see that the new proposal is significantly
less complex.

> 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).
[JRE] I don't see how the present proposal helps with forked calls where you
have multiple early dialogs created, any one of which can potentially send
an Early-Media header field asking the UAC to contact a media server. Is it
really any easier for the UAC to sort this out than to sort out RFC 3959/60?

> 
> 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.
[JRE] Also with RFC 3959/60 you can assign a different payload type to the
early session, if you wish. You can turn early media on and off with further
offer-answer cycles in UPDATE.

> 
> > 
> > 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.
[JRE] In your example it is proxy B that invokes early media by inserting
the Early-Media header field in the 180 response. If proxy B causes early
media to be played, then surely proxy B should have the capability of
stopping early media. A use case might be that proxy B is scripted to route
incoming INVITE requests to a particular target, which requires early media
to be played. Then, if there is no answer within a certain time, it might be
scripted to retarget to somewhere where early media is no longer required or
different early media is to be played.

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