Hello Deepak,
RTP states that in case a source changes its source transport address, it must also choose a new SSRC identifier . ( Refer to the last line of the description of SSRC as a field of the RTP Header. Section A.5.1, H.225 ). Hence, no SSRC collision will be registered. After changing the DSP (also resulting in change of IP address - assuming that it is associated with a different NIC), the source transport address as well as the SSRC changes as a result of which the receiver perceives this participant to be a new member in the session. Due to the soft-state approach of RTP, the information about the old transport address and the old SSRC would be removed subsequently (as it would no longer register any activity).
If the application requires a correlation between the new SSRC and the older one, the same can be achieved through the CNAME item. The CNAME item in the RTCP packets generated would be the same for both the sources. However, as one cannot wait for an RTCP packet to arrive to correlate, this is not fool-proof.
The above scenario is also the one seen in IPv6 mobility, wherein the IP address of the sender changes.
Regards, Aparna.
Deepak Jaiswal djai@sasi.com on 08/13/99 12:15:14 PM
Please respond to Deepak Jaiswal djai@sasi.com
To: rakeshj@wipinfo.soft.net (rakesh jain) cc: vittaln@agcs.com, h323implementors@imtc.org (bcc: Aparna Saha/HSS)
Subject: Re: RTP question!!
Deepak, Hi. If after changing DSP you are sending RTP/RTCP packets from new IP address that is IP address of new card, than i think, at receiver end it will be source conflict, because IP adress is different than the Old one. As a result the packets from the new card will be discarded. Pls let me know, if I am wrong. rakesh
Hello Rakesh,
You need to open a multicast channel where in a receiver can recieve packets from multiple sources.
With Regards, -- Deepak Jaiswal Multimedia Codecs Group djai@sasi.com Silicon Automation Systems Ltd. http://www.sasi.com #5, Corporation Division #67, HAL 3rd Stage, Tel: +91-80-5281461 x4115 Jeevan Bhima Nagar, Bangalore 560 075, India. Fax: +91-80-5276125 ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request@imtc.org with text "info"
Hello Aparna,
I agree that SSRC number needs to be changed when the transport address is changed.
Coming back to the original problem:
"How can this be done within RTP/RTCP protocol(without using H245 OLC etc) such that the receiver does not get confused with the sudden change in RTP sequence numbers and whatever else that is unique to a particular RTP transmitter?"
I.e, How does an application developed for uni-cast from a single source handle packets transmitted from multiple source, as the application can be confused with the change in RTP sequence number and SSRC.
Nagaraj, whenever the receiver application detect a change in the SSRC number, its should re-set its RTP-timestamp to system-time conversion routine.
Regards, -- Deepak Jaiswal Multimedia Codecs Group djai@sasi.com Silicon Automation Systems Ltd. http://www.sasi.com #5, Corporation Division #67, HAL 3rd Stage, Tel: +91-80-5281461 x4115 Jeevan Bhima Nagar, Bangalore 560 075, India. Fax: +91-80-5276125
Hello Deepak,
RTP states that in case a source changes its source transport address, it must also choose a new SSRC identifier . ( Refer to the last line of the description of SSRC as a field of the RTP Header. Section A.5.1, H.225 ). Hence, no SSRC collision will be registered. After changing the DSP (also resulting in change of IP address - assuming that it is associated with a different NIC), the source transport address as well as the SSRC changes as a result of which the receiver perceives this participant to be a new member in the session. Due to the soft-state approach of RTP, the information about the old transport address and the old SSRC would be removed subsequently (as it would no longer register any activity).
If the application requires a correlation between the new SSRC and the older one, the same can be achieved through the CNAME item. The CNAME item in the RTCP packets generated would be the same for both the sources. However, as one cannot wait for an RTCP packet to arrive to correlate, this is not fool-proof.
The above scenario is also the one seen in IPv6 mobility, wherein the IP address of the sender changes.
Regards, Aparna.
participants (2)
-
Aparna Saha -
Deepak Jaiswal