Yes it's as per RFC. This is normal behavior which can be seen with most of the practical deployment where UAS indicates *inactive* (neither capable of sending media nor receiving in particular state). In your step 4, why a=recvonly is sent, wouldn't it be a=sendrcv to get back the held call?
Best Regards, Vivek Batra -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Sander Rambags Sent: Friday, May 09, 2014 1:07 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] Call Hold Resume issue , inactive answer after sendonly No media stream after putting call on an off hold. 1. Call connected between A and B. 2. A holds the call with a=sendonly. 3. B sends 200 ok with a=inactive (In many cases this would be a=recvonly, but in some cases / vendors it is a=inactive) 4. A resumes the call with a=recvonly 5. B sends 200 ok with a=inactive So no media stream My question: A) Is the response in 3. according to RFC3264 ? B) What must A sent when put call off hold ? C) Other remarks on this issue ? Rg Sander _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
