inline
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.
I completely agree here. Sending a=inactive here indicates B's intent to not send media, nothing more. In addition, A should not expect B to process any received media if A continues to transmit. If B can only deal with a single codec, it should pick one and respond accordingly.
Regards, Bert
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
