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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 21 Oct 2010 16:00:15 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Oct 2010 20:21:51 -0400

[as individual]

Dale,

This is quite nice. You have covered a lot of obscure cases.

Obviously the constraint about reusing payload numbers is problematic. I 
think we should consider the possibility of relaxing it, though I don't 
know if we can get away with that after the fact or not.

ISTM that the fundamental reason for such a constraint is transient. 
When you have an existing session and then modify it, the change in the 
signaling and the change in the media packets do not happen 
synchronously. So when you make the offer you must be ready to receive 
media based on the new offer while you are still receiving media on the 
old offer. Similarly for sending.

If the codec associated with a payload type is changed then when a 
packet arrives it will be impossible to know which codec applies for it.

So, for a particular o/a exchange I think this rule must hold. But once 
that is in effect, and we know all media according to the old o/a has 
cleared the system, those old payload numbers no longer need be 
reserved. In reasonable cases, things should stabilize from one o/a 
before another o/a begins. (Though we can probably contrive a case where 
this is not so.)

Would such a change be sufficient to simplify the problems you have been 
dealing with in this draft?

	Thanks,
	Paul

On 10/21/2010 4:00 PM, Worley, Dale R (Dale) wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 27 Oct 2010 13:03:42 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

[as individual]

You are quite correct about this.  But re-reading my draft, I notice that the problem is remarkably theoretical:  In this case, the UA that does not execute the hold generates an offer to which the MOH server generates an answer.  The MOH server sends RTP using the codecs specified in the UA's offer.  Thus, there can be no confusion when the UA decodes the RTP, as the RTP is being sent based on what the UA specified.  The problem is the requirement that the codecs that the MOH server lists in its answer must meet the non-reuse requirement (despite that no media will be sent to the MOH server).  In practice I am sure that the hold-executing phone does not need to worry about this problem at all.

Dale