Brett,
IMO. Section 10.2 of 3264 seems to support that kind of mechanism
of placing the SDP inactive and requiring the other party to reINVITE to
activate the media but I do not think it applies in your scenario below.
The 10.2 signalling example seems to be written for initial call
setup signalling where one end point who cannot readily change SDP uses
that mechanism to delay activating media (DSP) until it knows for sure
what will be used. But you state below that "A and B have negotiated to use
codec 0" and so this is a in session
reINVITE for the purposes of Session Audit (?) or something but not for
the purpose of changing the negotiated SDP - either codec or held status.
So to me section 10.2 doesn't apply, as it is not call setup
signalling and the A party reINVITE is not attempting to change the
currently used codec or active status. Otherwise everytime you sent a
reINVITE to the B party the B party would deactivate the media and that
seems broken.
Regards,
Wayne
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.
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
This message is confidential, and may contain proprietary or legally privileged
information. If you have received this email in error, please notify the
sender and delete it immediately.
Internet communications are not secure. You should scan this message and any
attachments for viruses. Under no circumstances do we accept liability for any
loss or damage which may result from your receipt of this message or any
attachments.
******************************************************************************
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
