Hello Dale, Thanks for replying.
On Wed, 2014-12-10 at 21:35 -0500, Dale R. Worley wrote: > There is a discussion of the use of multicast in RFC 3264 section 5.2 > (which is considerably different from the discussion in the first > version of SIP in RFC 2543 appendix B): <snip> > 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. This is the exactly what I meant. While RFC 2327 and, as you have pointed it out, RFC 2543 only talks about the receiver of the SDP, RFC 3261 seems to explicitly forbid the offerer from sending on streams marked as recvonly. I'm wondering what was the reason behind this change from RFC 2543. Session updates where the roles of the offerer and answerer are reversed? > 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. The main obstacle appears to be the fact that there is no way to express support or willingness to use multicast, while leaving it up for the other party to select the multicast address. > On the other hand, I've never heard of anyone attempting to use > multicast within a SIP dialog. What we would like to do is to use SIP for setting up multimedia sessions that *are not* VoIP calls, in the context of AES67. SIP is already required by AES67 for setting up unicast streams, and it would make sense to use it for multicast, too. Thanks, Jānis _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
