Subject: Re: [dispatch] New Version Notification for draft-worley-service-example-04

From: "Scott Lawrence" <[email-masked]>
Date: Tue, 02 Feb 2010 13:31:07 -0500

On Thu, 2010-01-28 at 13:45 -0500, Dale Worley wrote:
> On Sun, 2009-12-13 at 07:41 -0500, Scott Lawrence wrote:
> > The draft doesn't go into much detail on the specifics of the advantages
> > over the method described in 5359 (and other methods in use); it could
> > probably use some expansion in that area because the advantages are
> > real.
> 
> The current text is:
> 
>    This technique for providing music-on-hold has advantages over other
>    methods now in use:
> 
>    1.  The original dialog is not transferred to another UA, so the
>        "remote endpoint URI" displayed by the remote endpoint's user
>        interface and dialog event package[dialog-event] does not change
>        during the call.[service-examples]
> 
>    2.  Compared to [service-examples], this method does not require use
>        of an out-of-dialog REFER, which is not otherwise used much in
>        SIP and may not be handled correctly by authorization mechanisms.
> 
>    3.  The music-on-hold media are sent directly from the music-on-hold
>        source to the remote UA, rather than being relayed through the
>        executing UA.
> 
>    4.  The remote UA sees, in the incoming SDP, the address/port that
>        the MOH source will send MOH media from, thus allowing it to
>        render the media, even if it is filtering incoming media based on
>        originating address as a media security measure.
> 
>    5.  The technique requires relatively simple manipulation of SDP, and
>        in particular: (1) does not require a SIP element to modify
>        unrelated SDP to be acceptable to be sent within an already
>        established sequence of SDP (a problem with
>        [service-examples-11]), and (2) does not require converting an
>        SDP answer into an SDP offer (which was a problem with the -00
>        version of this document, as well as with [service-examples-11]).
> 
>    6.  It complies with the payload type number rules.[offer-answer]
> 
> What do you think needs to be added or expanded?  In regard to RFC 5359
> specifically, items 1 and 2 call out the improved behavior.

Since the goal is to update 5359, I think that there should be an
explicit section that says, in effect: "Here is what is wrong with how
it is done in 5359, and why this proposal is better".  For each of the
above, rather than saying "this way doesn't do xyz", say
"service-examples-11 does xyz, and that is a problem because...".

Some specifics that you leave unsaid:

What's wrong with changing the remote party id on a call just because
you get put on hold?

In what way is sending an out-of-dialog REFER unreliable?  When wouldn't
it work?  (neither From headers nor Contact addresses are always
routable).

What's wrong with relaying media through the UA executing the hold?  

What's wrong with manipulating SDP?  

What's the big deal with payload number rules?  What problem does that
cause?