"A participant need not use the same SSRC identifier for all the RTP
sessions in a multimedia session;" -- RFC 1918, Section 3.
In practice, many devices do not expect the SSRC to change routinely.
Heuristically, in an ordinary phone call, a changing SSRC may indicate
that two streams are being sent to the same RTP sink erroneously.
Telica/Lucent/Alcatel: The Telica Plexus 9000 / Lucent Compact
Switch / Alcatel-Lucent Network Gateway has a parameter "xtalkPeriod":
Identifies the number of consecutive RTP packets with no change in any
remote parameter (SSRC, UDP_PORT, IP_ADDRESS) to qualify the current
RTP stream as valid. The factory default is 200." (Although, I'm not
sure what "valid" means; I believe the device will generate an alarm/
alert/trap if it receives traffic from a different SSRC after
receiving 200 packets from the first.)
Polycom: I've been told by Polycom employee that some of the Polycom
products will latch onto the first SSRC received, and expect to
continue to receive it. But I can't find that in their documentation.
The Polycom "app" logs to show when the SSRC changes, but apparently
it didn't cause those call to fail.
${Level(3)'s Gateway}: In one case, customers had problems with
Polycom phones that occurred when Level(3)'s gateways changed the
SSRC; in particular, the gateway would transmit four RTP frames with
one SSRC value ssrc[i], then change and transmit more RTP with SSRC
value ssrc[j], where ssrc[i] != ssrc[j].
Acme Packet: To the best of my knowledge, the Acme Packet SBC can also
latch on streams, but does it based on IP addresses and port numbers,
not the SSRC within. So the SSRC can change without the SD caring.
On Jul 16, 2009, at 8:18 AM, Michael Hirschbichler wrote:
> Hi,
>
> but is there a standard defining the behaviour? I guess, there is no
> need to compare SSRC of every incoming RTP-packet on the client
> (Well -
> security reasons as RTP-spoofing left beside). I am looking for a
> quotable reference regarding the SSRCs inside of RTP-streams managed
> by
> SIP/SDP and therefor need some help,
>
> thx again
> and br
> Michael
>
> Shanbhag, Somesh (NSN - IN/Bangalore) wrote:
>> I think most of the times it depends upon the implementation.
>>
>> In one of the product which I had worked on, this was one of the
>> configurable options to be turned on if we have to detect some kind
>> of "rogue" packets.
>>
>> There will be different checks to be made to consider the packet as
>> the "rogue" and it depends, if we have to honour.
>>
>> Thanks, Somesh
>>
>> -----Original Message----- From:
>> sip-implementors-boun...@lists.cs.columbia.edu
>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
>> ext Michael Hirschbichler Sent: Thursday, July 16, 2009 1:46 PM To:
>> sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors]
>> Changing SSRC during Call
>>
>> Hi all,
>>
>> is it a problem, when a RTP-stream during a call is replaced by
>> another RTP-stream?
>>
>> Let's assume, stream with SSRC1 is arriving at a UAC
>> (100.11.12.13:12345). Now, the stream stops (without any
>> SIP-signalling like Re-INVITEs, etc.) and a stream with SSRC2 is now
>> arriving at 100.11.12.13:12345 instead of SSRC1. Is there a
>> regulation defining to block a changing SSRC? Or is it satisfying
>> that the stream is arriving at the same socket (defined in the SDP of
>> the INVITE) like the one before?
>>
>> Thx in advance and br, Michael
>> _______________________________________________ Sip-implementors
>> mailing list Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
Mark R Lindsey lind...@e-c-group.com +12293160013 http://e-c-group.com/~lindsey
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
