> 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
