Attila, Another small nit, as long as a different port number is used by each participant, using same multicast address is not a problem. Since you can demux packets based on port numbers. However, since multicast ports are not local resources - different participants have to co-ordinate to not use the same port numbers.
[Not to mention there is some fun involved with operating systems not allowing multiple listens on same port etc - which make multicast a lot of fun ;-)] thanks Arun -----Original Message----- From: Punj, Arun Sent: Friday, May 18, 2007 10:34 AM To: Attila Sipos; Punj, Arun; Sip-implementors@cs.columbia.edu Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Does anyone know multicast? (was RE: RFC3264 offer/answer - multicast) Attila, See inline. I should add, I have never used a single multicast address for multiple senders - so everything I write below is mere conjecturing. thanks Arun -----Original Message----- From: Attila Sipos [mailto:[EMAIL PROTECTED] Sent: Friday, May 18, 2007 10:11 AM To: Punj, Arun; Sip-implementors@cs.columbia.edu Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] Does anyone know multicast? (was RE: RFC3264 offer/answer - multicast) Thanks Arun. Nice answer. That helps a lot. Just one more thing regarding this line: >>All the participants in a call who indicate capability >>to send on a given multicast address can send on that multicast. With RTP, is it unlikely that more than one participant in a Multicast session would send RTP? For example, say you have 3 Participants and they all send can send and receive RTP - could this work? [ap] In practise I have not seen any device which does that. Although in theory this could be done by using source id. You could for example, use extended RTP header ( 16 byte header ) which contains informatin to demux streams based on sender id. Or you could use, source IP address to distinguish packets from various sources. [You could infact put source ip address in extended RTP header] However, this works if you have indicated in the SDP which source id you would use. [ap]Like I said, I have not seen any device actually do it. Wouldn't all the RTP sequence numbers be misaligned and cause confusion for the receivers? If not, how does RTP behave in such scenarios? [ap] Before you do any RTP processing you must demux streams or the RTP will run into sequence and time stamp errors. Although you could [in practise] ignore any such error and simply pump all audio packets to audio [de]codecs. I have had to write code to ignore timestamp and sequence number errors to interwork with certain devices. [ap]It should be noted that video is a totally different beast in this regard. Audio is amenable to *mixing* but not the video. So the ability to demux streams *is a requirement* for video. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Punj, Arun Sent: 18 May 2007 14:30 To: Attila Sipos; Sip-implementors@cs.columbia.edu Cc: [EMAIL PROTECTED] Subject: Re: [Sip-implementors] Does anyone know multicast? (was RE: RFC3 264 offer/answer - multicast) Attila, It is my interpretation that the directionality of the stream is reversed in case of multicast. So for example, in the unicast case, if a participant lets say party1 generates an SDP with m=audio 30000 RTP/AVP 0 c=10.0.0.10 a=recvonly It means party 1 will *only* receive audio at port 30000 and address 10.0.0.10. Where in case of multicast m=audio 30000 RTP/AVP 0 c=239.199.0.10 a=sendonly Indicates that party 1 can only transmit video at address 239.199.0.10 and port 30000. That is the *direction* of offer in SDP is from transmit perspective rather than receive perspective ( in terms of port numbers and multicast IP address). Although arguably you could receive on the same port/address in multicast. Typically, if a multicast offer is made the answer would make sense in multicast only. However, it is allowed that a unicast offer get a multicast reply. ( internet radio, would be an example, where client could send a unicast request/offer, and the server could reply back either with a unicast or multicast answer ). All the participants in a call who indicate capability to send on a given multicast address can send on that multicast. So for a chat session, all the participants could use a single multicast address with every participant using that for a group chat. ( Every party ignoring its own multicast out). To re-iterate, all participants who indicate that they can send on a given multicast address are allowed to send RTP on that multicast address. thanks Arun -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos Sent: Friday, May 18, 2007 8:42 AM To: Sip-implementors@cs.columbia.edu Subject: [Sip-implementors] Does anyone know multicast? (was RE: RFC 3264 offer/answer - multicast) Does anyone have a clue about multicast and the questions below? Any help would be greatly appreciated. Regards, Attila -----Original Message----- From: Attila Sipos Sent: 17 May 2007 17:30 To: Sip-implementors@cs.columbia.edu Subject: [Sip-implementors] RFC 3264 offer/answer - multicast I have some questions on section 5.2: 5 Generating the Initial Offer 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. I am confused about this. It seems to say that if the offer has recvonly then both the "offerer and answerer" can only receive on that port. I am sure my interpretation is wrong - what is the correct interpretation? ========================= Also regarding, "6.2 Multicast Streams", generating the answer, it seems that if the offer was a multicast SDP, the answer has to be an almost identical mulicast SDP. Fine. But what happens if the offer was unicast and the desired answer is multicast? For example, if you sent an INVITE to a server with unicast but the server wanted to use multicast to send the same RTP to everyone, can this happen? Would there need to be anything special in the SDP? ========================= And who is allowed to send (say RTP) to a multicast IP address? Surely it only makes sense that the server sends the multicasts while the clients keep quiet. ?? Regards, Attila _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
