Jānis Rukšāns <janis.ruks...@gmail.com> writes: > 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.
Yes, the interpretation of "sendonly" and "recvonly" in regard to what direction is being described is opposite in the case where SDP is carried by SIP compared to the case where SDP is published to describe a multicast session. There is a discussion of the use of multicaset in RFC 3264 section 5.2 (which is considerably different from the discussion in the first version of SIP in RFC 2543 appendix B): 5.2 Multicast Streams 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. This differs from the unicast view, where the directionality refers to the flow of media between offerer and answerer. Beyond that clarification, the semantics of an offered multicast stream are exactly as described in RFC 2327 [1]. Which seems to suggest that if the media address is a multicast address, it is unusable for sending media from one UA to the other if it does not have a=sendrecv. > 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. That does appear to be true, that the only case that works is a single m= line with a multicast address that both UAs use for sending/receiving media. On the other hand, I've never heard of anyone attempting to use multicast within a SIP dialog. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
