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
