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

From: "Dale Worley" <[email-masked]>
Date: Thu, 28 Jan 2010 13:45:07 -0500

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.

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 28 Jan 2010 13:54:13 -0500

On Thu, 2009-12-10 at 15:20 -0500, Shekh-Yusef, Rifaat (BVW:9T16) wrote:
> Question about section 2.8, Dialog/Session Timers:
> 
> You described two approaches to this issue:
> 
> 1. The executing UA supports timer per dialog
> 2. The executing UA forwards the refresh requests to refresh both
> dialogs
> 
> What is the advantage of the second approach over the first one?
> 
> The second approach might be a little challenging.
> For example, think about the scenario where the executing UA has
> established a dialog with the other party with SE: 3600, but the Min-SE
> of the Music Source is 7200. You might have a problem if the Music
> Source is the refresher.

Yes, it does look like it would be difficult to arrange for session
timer updates to be passed through and to be handled correctly in all
cases.  I'm no expert on RFC 4028, and it looks like it is possible to
change the refresh interval during a dialog.  But getting the logic
correct would probably be much harder than having the executing UA
handle session timers in the default way on each of the two dialogs.

Dale