When implementing call hold service, RFC 3264 says:
"The recipient of an offer for a stream on-hold SHOULD NOT automatically
return an answer with the corresponding stream on hold".
It is not clear the reason of this explicit "violation" of the RFC itself
(RFC says interop problems with 3pcc, any real world example about?). On the
other hand, it leaves one unsolved issue: the holding UA may use either the
sendonly or inactive attribute to hold the remote UA, and the remote UA may
choose the inactive state in both cases. If the holding UA doesn't receive
and SDP offer is unable to understand if it has to continue to generate RTP
flows to the remote UA or not.
The draft draft-ietf-sipping-service-examples-10 shows a lot of examples
where the UAS answers to the holding SDP offer, so I'm assuming it doesn't
hurt too much. I personally experienced that some commercial UAs (especially
recent releases) drop the call when they don't receive an answer.
What is the right way to do? What is the most common real world scenario?
Thanks
Andrea
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
