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

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: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale)
> Sent: 21 October 2010 21:00
> To: sipcore@ietf.org
> 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 