Jānis Rukšāns <janis.ruks...@gmail.com> writes: > 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?
My guess is that at the time, people conceptualized the use of multicast within SIP in one way: There is a single multicast address/port, both UAs send media to it, and both UAs subscribe to the address/port to receive the media. >> 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. It seems to me that this is a case where additional standards development needs to be done because it is a different usage than anyone has worried about until now, and probably a difference usage from what anyone has done before. Fortunately, you won't have to worry much about upward-compatibility, as there is no previous usage. It would also help to have an I-D that documents the usage situations and how you use SIP within them, as well as what you want the SDP to do. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
