Trace Logs - Tuning to new SSRC

[jag]

What does this mean?

 

5] 2008/08/05 16:55:56: Tuning to new SSRC

[Vodia PBX]

What does this mean?

 

[5] 2008/08/05 16:55:56: Tuning to new SSRC

 

Someone is sending RTP from another source. According to IETF it is legal, but raises questions where the RTP comes from, that's why the PBX writes something in the log. Only in the case of MoH it makes sense, IMHO.

[global_s]

Hello,

we are seeing this same log entry when a customer tells us their connection drop.

 

Can we know where the new RTP comes from? we suspect it might be our firewall that is blocking this unknown source and we would like to whitelist the address. Could this be a possible cause of the audio drop?

 

can we make some changes on our side to avoid this from happening?

[Vodia PBX]

Good point with the logging. We'll add that in the next release. Right now you will see that only with PCAP/Wireshark.

 

The change happens only of the other source did not send anything for at least 100 ms. This is to avoid that someone "steals" the stream while staying still reasonably within the RFC bounds, and it does usually mean that the original sender did stop sending traffic. If you are using SRTP, the context has also be re-initialized which raises the question of the value of the SRTP rollover counter. When the SSRC value is changed, the PBX must assume that it has been reset to 0. If the problem occurs only after longer conversation it might point at problems in that area (when the ROC is more than 0).

[global_s]

The change happens only of the other source did not send anything for at least 100 ms. This is to avoid that someone "steals" the stream while staying still reasonably within the RFC bounds, and it does usually mean that the original sender did stop sending traffic. If you are using SRTP, the context has also be re-initialized which raises the question of the value of the SRTP rollover counter. When the SSRC value is changed, the PBX must assume that it has been reset to 0. If the problem occurs only after longer conversation it might point at problems in that area (when the ROC is more than 0).

 

I'm not following, if the pbx don't receive any RTP from the external party it changes to what? How does it know where to look for the RTP? I don't see in the sip messages any reference to a new RTP stream.

 

What if, the other party did send RTP, but the packets are lost for 100 ms; the pbx thinks it needs to switch to something else. is it actually the cause of my call drop? I'm asking you because I really don't know what could be.

 

Thanks

[Vodia PBX]

Well according to SIP, RTP may come from anywhere, anytime! For example, this is the way that the SIP standard proposes the implementation of music on hold, and the MoH server may be sitting anywhere in the Internet... The RFC authors must have lived in a world when the Internet was friendly and nobody would send anything bad to a PBX operating on a public IP!

 

100 ms does not necessarily mean that the PBX gives up on the connection; it just means it opens it's arms to new RTP stream that would arrive on the RTP port. That does not have to be a call drop. For example, some phone stop RTP when the mute button is active, or they slow it down to a packet per second or so. Some other devices don't sent traffic during silence (silence suppression) to save bandwidth, which is also okay. Unfortunately there is no way on the PBX side that can safely tell the PBX if the call dropped or it is a temporary thing.