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.
1. Should Party A reinvite with a=inactive?
2. Should Party B be responsible for removing the "on hold" since it
generated first request to do so?
Party A- Party B-
Invite ------offer#1=sendrecv-------> Codecs 96 107 103 13 100
<------- answer#1=inactive----200ok Codecs 96 107 103 13 100
(B puts call on hold)
Reinvite-------offer#2=inactive-------> Codecs 96 100 (media
lockdown)
<-------answer#1=inactive----200ok Codecs 96 100
(A also puts the call on hold)
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
