Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Nov 2010 11:23:38 +0100

Dale,

I haven't reviewed it in detail, but I see there is no mention of RTCP. Perhaps it isn't really relevant, except that it provides another reason why the media server needs to supply an IP address and port - even though it will not receive RTP, it will receive RTCP. The RTCP port could be implicit or explicit.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Worley, Dale R (Dale)
> Sent: 21 October 2010 21:00
> To: [email-masked]
> Subject: [sipcore] Reviewers needed for new music-on-hold technique
> 
> I've written draft-worley-service-example to describe a 
> music-on-hold technique which has some advantages over the 
> technique in RFC 5359.  (The two are mutually compatible, and 
> both are compatible with almost all SIP UAs.)  I am advancing 
> this as an AD-sponsored RFC.  I think I've fixed the last 
> wrinkles and would like people to review the draft.
> 
> The -05 changes describe that (as in other third-party 
> situations) it is not possible to handle codec numbers 
> exactly correctly in all situations.  But following certain 
> guidelines provides correct behavior in the vast majority of cases.
> 
>       Session Initiation Protocol Service Example -- Music on Hold
>                     draft-worley-service-example-05
> 
>    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, and 
> 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.
> 
> Thanks,
> 
> Dale
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 1 Nov 2010 13:46:47 -0400

________________________________________
From: Elwell, John [[email-masked]]

I hadn't thought about RTCP, but I'll put a note about it in the next version.

Thanks,

Dale