I support what Dale says. For more info, see section 5.3 of RFC 6337.
Thanks,
Paul
On 9/15/11 4:59 PM, Worley, Dale R (Dale) wrote:
>> From: Sproul, Barry K [barry.spr...@verizonwireless.com]
>>
>> I have an issue between 2 vendor platforms that causes permanent audio
>> on hold. Initial invite from party A contains SDP offer with sendrcv
>> and multiple codecs. Party B returns 200ok with SDP answer and
>> includes attribute of a=inactive with multiple codecs. Party A
>> reinvites with 2 preferred codecs to lock down media also adds the
>> a=inactive attribute. At this point the call is without audio both
>> directions indefinitely. I cannot find this scenario explained in RFC
>> 3264. I can find example of a=inactive in the offer but not answer.
>
> Each side is responsible for managing the "on hold" state that it
> creates. Its current on-hold state is shown by whether it indicates
> that it is willing to receive media. When a UA provides an offer, it
> should offer all media directions that it is willing to support at
> that moment, viz., sendrecv if it is not on-hold, sendonly if it is on
> hold and willing to provide on-hold media, and inactive if it is on
> hold and not willing to provide on-hold media. When a UA provides an
> answer, it should offer all media directions that are in the offer and
> that it is willing to support.
>
> In this case, A initially indicates that it is not placing the call on
> hold by offering sendrecv. B answers that it has the call on-hold and
> is not providing on-hold media.
>
> When A re-INVITEs, it should offer sendrecv again, as that is what it
> is willing to do at that moment. When A sends inactive, it is
> indicating that it has placed the call on-hold and is not providing
> on-hold media, despite that A's user has not executed the hold
> function.
>
> Note particularly that when a UA provides an offer, it does *not* copy
> the directionality from the SDP last provided by the other UA, it
> offers everything that it is willing to support at that time.
>
> Dale
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
