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

From: "Rifaat Shekh-Yusef" <[email-masked]>
Date: Thu, 10 Dec 2009 15:20:14 -0500

Hi Dale,

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.

Thanks,
 Rifaat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Worley, Dale (BL60:9D30)
Sent: Monday, October 26, 2009 2:18 PM
To: DISPATCH
Subject: Re: [dispatch] New Version Notification
fordraft-worley-service-example-04

I've submitted a new revision of a service example for music on hold.
Since the design is getting debugged and we've seen implementations in
real products, I would like to propose that this draft be sent to Bliss
in order to be approved as an addition to the service examples RFC
(5359), as the method described in the draft has some advantages
relative to the method in section 2.3 of RFC 5359.

Dale

On Sun, 2009-10-25 at 17:51 -0700, IETF I-D Submission Tool wrote:
> A new version of I-D, draft-worley-service-example-04.txt has been 
> successfuly submitted by Dale Worley and posted to the IETF 
> repository.
> 
> Filename:	 draft-worley-service-example
> Revision:	 04
> Title:		 Session Initiation Protocol Service Example --
Music on Hold
> Creation_date:	 2009-10-25
> WG ID:		 Independent Submission
> Number_of_pages: 32
> 
> Abstract:
> The "music on hold" feature is one of the most desired features of 
> telephone systems in the business environment.  "Music on hold" is 
> where, when one party to a call has the call "on hold", that party's 
> telephone provides an audio stream (often music) to be heard by the 
> other party.  Architectural features of SIP make it difficult to 
> implement music-on-hold in a way that is fully compliant with the 
> standards.  The implementation of music-on-hold described in this 
> document is fully effective and standards-compliant, but has a number 
> of advantages over the methods previously documented.  In particular, 
> it is less likely to produce peculiar user interface effects and more 
> likely to work in systems which perform authentication than the method

> of RFC 5359.

http://tools.ietf.org/html/draft-worley-service-example-04

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Scott Lawrence" <[email-masked]>
Date: Sun, 13 Dec 2009 07:41:33 -0500

On Tue, 2009-10-27 at 20:00 +0900, Shida Schubert wrote:
> Dale,
> 
>   Is your intent to update RFC5359 to have this
> replace the current section 2.3 or do you see this draft
> as a standalone informational draft describing a better
> way of doing Music on Hold?

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.

This feature (providing a third party audio stream during 'hold') is, as
the draft says, an important requirement in many deployments, and one
whose present record for interoperability is not very good.  I am
strongly supportive of having this work sent to BLISS to be progressed
as an Update to 5359.

One nit on the terminology in the draft: I'd suggest replacing the
references to preventing 'SPIT' with something along the lines of 'as a
media security measure'; the term 'SPIT' is much more sweeping and not
specifically descriptive of what a UA is doing when deciding whether or
not to render a media stream within an existing call.