Brett,
Do I understand - it sounds like B is doing this not because it wants to put A on hold, but because it wants A to choose one codec, and wants to ensure that no data is transmitted until that happens???
I see no reason why A should feel it should do anything in this situation other than wait for B to take it off hold.
Paul
Brett Tate wrote:
If device A indicates a non-hold offer to B and B answers with a hold, is
there any reason for B to think that A should send a re-invite to try
pulling B off hold?
My answer is no. However the situation has arisen during interoperability testing and the implementers of device B are trying to quote rfc3264 section 10.2 as justification why A should send a re-invite after B has placed the call on hold (a=inactive).
A and B have negotiated to use codec 0. A re-invites B with codecs 0 4 18. B sends 200 response with codecs 0 4 18 and a=inactive.
Thus B has placed the call on hold. Is A now supposed to somehow know to re-INVITE B again using a single codec so the call is no longer on hold? My answer is no.
If B can only support a single codec at time, B should answer with a single codec instead of a=inactive and all the codecs.
If you agree or disagree with me, please post a reply to the list to help us close the debate.
Thanks in advance.
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
