[SIPForum-discussion] RTP ssrc change during a call

[Gunnar Hellström]

Hi Raghul,

RFC 3550 RTP says that there are two cases when the SSRC can change:
1. If an SSRC conflict is detected ( someone else using the same SSRC )
2. If the source changes its transport address.
" If a source changes its source transport address, it must also choose 
a new SSRC identifier to avoid being interpreted as a looped source (see 
Section 8.2)."

Another place mentions:
"Since the SSRC identifier may change if a conflict is discovered or a 
program is restarted"

Section A.1 contains a description of checks to do to decide if an RTP 
packet is valid. Decisions on new appearing SSRC is included in that 
description.


Summary: There are cases when the behaviour you have seen is valid. It 
should also be indicated in RTCP.

Regards

Gunnar

-----------------------

Raghul Prasanna skrev 2011-08-12 10:36:
> Hello All,
>
> I have seen a call where the far end initially starts with a SSRC and 
> then the next rtp from the same source has different ssrc field, I am 
> looking for the wireshark I had so that  I can share it with you guys, 
> will post it if I find that.
>
> Is this acceptable? I remember the user saying one way audio or 
> something like that.
>
> This is not a conference call, because I was wondering if the far end 
> was a mixer and the rtp was actually coming from different source, but 
> then realised that it will have CSRC if it was from a mixer to 
> identify the actual source.
>
> Anyways is it OK to change SSRC by a source during a call, if it can 
> what will be effect on the call?
>
> Thanks,
> Raghul
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20110816/b9dbb430/attachment-0002.html>