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

[Paul Kyzivat <[e-mail]>]

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

On 10/27/2010 2:15 PM, Worley, Dale R (Dale) wrote:
> [second attempt to send]
>
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Paul Kyzivat [[e-mail]]
>
> [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
>