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

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 27 Oct 2010 14:15:39 -0400

[second attempt to send]

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

[as individual]

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.
_______________________________________________

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2010 16:49:15 -0400

I'm quite sure the constraint isn't there for the pain or benefit of an 
MOH server. Its a constraint that applies on a single session between a 
single pair of UAs that are using reINVITE to renegotiate the codec they 
are using. In that context it makes sense, for one o/a cycle.

What doesn't make sense is extending it for the life of the session.

	Thanks,
	Paul