cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays

Additional RTP flow coming from a SIP trunk (Asterisk) mixed by IPPhone

579
Views
0
Helpful
0
Comments
This document was generated from CDN thread

Created by: Stefania Oliviero on 16-10-2013 10:22:35 AM
HI to all, my customer has a CUCM 8.6, linked to an Asterisk via a SIP trunk.
Sometimes, it happens that on the Asterisk side it is generated or never dropped RTP flow sent towards IPPhone (7975).
By the user point of view, when on the phone is received a new call, audiois resulting in metallic voice.

Starting from the fact that it is a mistake from the Asterisk side they have to solve, but my customer asked me why the IPPhone accepts this additional RTP flow.
I think IPPhone behaves correctly, but I don't know SIP and RTP protocols very well, so can anyone help me to answer to my customer ooviding me more details ?

Thanks, Stefania.

Subject: RE: Additional RTP flow coming from a SIP trunk (Asterisk) mixed by IPPhone
Replied by: David Staudt on 16-10-2013 12:05:03 PM
(Assuming the second call is the correct audio stream, but poor quality - vs. some sort of combined playback of the two streams)

From a phone perspective, I would guess this behaviour could be considered a 'continuous UDP DoS attack'.  Not sure how the phone might protect itself in such situations, but protections may be more or less effective depending on whether the stale incoming stream has the same Port, the same IP, or both.  I can imagine a scenario where if both, that the phone is only able to discard the extraneous packets after accepting/handling/and inspecting them to validate the stream identifier, which might cause significant performance degradation (and resulting poor audio quality.)
There may be some technical possiblity of having the phone better handle such DoS situations, but probably unlikely to get much traction, especially if the problem is caused by a broken/misconfigured 3rd party component.
Content for Community-Ad

This widget could not be displayed.