Hello,
We are considering adding SIP as one of the means of session negotiation to some of our products that support both unicast and multicast. I believe that I've stumbled upon a contradiction in / between RFC 3264 and RFC 2327/4566 with regard to the interpretation of the sendonly and recvonly attributes for multicast streams. The intent of RFC 2327 seems to be for the issuer of the SDP to use recvonly when it is sending on the particular multicast group (or acting on behalf of the sender). This contradicts with RFC 3264, which states that "if a session description contains a multicast media stream which is listed as receive (send) only, it means that the participants, *including the offerer* and answerer, can only receive (send) on that stream." (Section 5.2, emphasis mine) If the above is interpreted literally, no media can be exchanged between the participants unless the stream is marked as sendrecv. If the stream is marked as recvonly, all participants can receive, but none can send, and vice versa for sendonly. To make matters worse, the common interpretation (as common it may be) seems to be doing the exact opposite of what is mandated by the RFCs, as revealed by a cursory search for "sip sdp multicast" (see [1] and [2]). That is, if the offerer is willing to send a media stream to a multicast address, the stream is marked as sendonly in the offer (and supposedly will be marked as recvonly in the answer). Any thoughts on this matter? The apparent limitation of RFC 3264 can be overcome by treating the sender (receiver) and offerer as separate entities, where the offerer is only acting on behalf of the sender, and not processing any media itself (while in reality it is). On the other hand, using sendonly as shown in [1] and [2] is less confusing, and has the advantage of using the same mechanism for both unicast and multicast streams. On a related note, the offer/answer model seems to be almost completely unusable in situations where, in addition to unicast, either or both parties support and would prefer using multicast, where unicast is used in one direction and multicast in the other, or where different multicast addresses are used by each sender. [1] http://stackoverflow.com/questions/11256362/is-sdp-sendonly-means-to-open-one-rtp-audio-stream-in-this-case [2] https://lists.cs.columbia.edu/pipermail/sip-implementors/2007-May/016611.html Thanks, Jānis _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
