djai at SASI.COM
Fri Aug 13 07:12:07 EDT 1999
I agree that SSRC number needs to be changed when the transport address is
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.
Multimedia Codecs Group djai at 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
> 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.
More information about the sg16-avd