FreeSWITCH

rtp auto adjust takes too long, loosing from 300ms to 1s of audio in beginning of session

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Platform:
    Linux x86_64/gcc
  • CPU Info:
    AMD Athlon(tm) 64 X2 Dual Core Processor 4000+
  • FreeSWITCH GIT Revision:
    HEAD (2012-04-25)
  • Reproduced with GIT HEAD?:
    YES

Description

For devices behind NAT that don't use STUN or SIP ALGs, FS waits to receive 10 packets (switch_rtp.c line 3232) before sending RTP to the address used by the device instead of the one advertised in SDP.

The bad thing in case of PCMA@20ms, is that it means that the first 200ms (at least) of audio are not received by the device. In practice, this delay is between 300ms and 1 full second.

Is there an issue with lowering this "adjust" to just 1 packet instead of 10 in FS?

Out of curiosity, I checked how it's done in Asterisk (res_rtp_asterisk.c). Apparently, anytime Asterisk receives a single RTP packet from a different address (and not just once as in FS), it starts sending to that address. Which is quite cool because you could hijack audio of any session by just sending dummy RTP packets to that port a bit faster than the real source.

As for FS, it has an adjust window, and does the IP change only once, so it would be way harder to do the same, even with an adjust of a single packet.
  1. Text File
    NEW_rtp_autoadj.txt
    26/Apr/12 11:08 AM
    6 kB
    François
  2. Text File
    rtp_autoadj.txt
    26/Apr/12 6:09 AM
    6 kB
    François

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Anthony Minessale II added a comment -
You need several packets to allow for devices that reinvite media and send legacy packets during the transformation from the old location that may cause the adjust to go back the other way or to the wrong host.

The real solution is to not rely on this mechanism as its a catch-all for broken devices but I can consider a patch to make the window length configurable.
Show
Anthony Minessale II added a comment - You need several packets to allow for devices that reinvite media and send legacy packets during the transformation from the old location that may cause the adjust to go back the other way or to the wrong host. The real solution is to not rely on this mechanism as its a catch-all for broken devices but I can consider a patch to make the window length configurable.
Hide
Permalink
François added a comment -
Here is the patch, I named the parameter rtp-auto-adjust.

Compiles, but I couldn't test it so far.

Would a valid option be to activate the autoadjust only if those broken devices are detected in SIP header (src IP != IP in SIP headers)?
Show
François added a comment - Here is the patch, I named the parameter rtp-auto-adjust. Compiles, but I couldn't test it so far. Would a valid option be to activate the autoadjust only if those broken devices are detected in SIP header (src IP != IP in SIP headers)?
Hide
Permalink
Anthony Minessale II added a comment -
NO there is no way to detect this problem it happens all the time without warning.
Show
Anthony Minessale II added a comment - NO there is no way to detect this problem it happens all the time without warning.
Hide
Permalink
Anthony Minessale II added a comment -
I think you should call it rtp-auto-adjust-window and make sure its identical behavior by default.
 
Show
Anthony Minessale II added a comment - I think you should call it rtp-auto-adjust-window and make sure its identical behavior by default.  
Hide
Permalink
François added a comment -
Well actually the autoadj_window is already used to deactivate auto adjust after X packets when "switch_sockaddr_get_port(rtp_session->from_addr)" returns false (switch_rtp.c, line 3266).

Wait a second... It actually looks useless as this check will always return something...

Ok then, i'll redo that patch, remove that block and reuse that variable.
Show
François added a comment - Well actually the autoadj_window is already used to deactivate auto adjust after X packets when "switch_sockaddr_get_port(rtp_session->from_addr)" returns false (switch_rtp.c, line 3266). Wait a second... It actually looks useless as this check will always return something... Ok then, i'll redo that patch, remove that block and reuse that variable.
Hide
Permalink
François added a comment -
Here is the patch, currently compiling and testing.
Show
François added a comment - Here is the patch, currently compiling and testing.
Hide
Permalink
Anthony Minessale II added a comment -
well actually the code you removed will keep the window from ever closing?

I guess its 2 params one for the window in which its ok to look for auto adj and one for how many in a row have to be from the same host.
so I was rushing on my last comment ;)

so probably one or both of these params, the function could take both at once to set the number of frames to trigger it and the number of frames the window is open for

rtp-auto-adjust-target
rtp-auto-adjust-window

sorry

Show
Anthony Minessale II added a comment - well actually the code you removed will keep the window from ever closing? I guess its 2 params one for the window in which its ok to look for auto adj and one for how many in a row have to be from the same host. so I was rushing on my last comment ;) so probably one or both of these params, the function could take both at once to set the number of frames to trigger it and the number of frames the window is open for rtp-auto-adjust-target rtp-auto-adjust-window sorry
Hide
Permalink
Jeff Lenk added a comment -
Francois is any action needed here?
Show
Jeff Lenk added a comment - Francois is any action needed here?
Hide
Permalink
François added a comment -
I had that on hold, will review and test asap given Anthony's comment.
Show
François added a comment - I had that on hold, will review and test asap given Anthony's comment.
Hide
Permalink
Ken Rice added a comment -
Francois, can you follow up on this bug?
Show
Ken Rice added a comment - Francois, can you follow up on this bug?
Hide
Permalink
João Mesquita added a comment -
Francois, hope all is well. Did you have any time available to review this?
Show
João Mesquita added a comment - Francois, hope all is well. Did you have any time available to review this?
Hide
Permalink
João Mesquita added a comment -
Please, reopen if this is still an issue. No news from reporter after several weeks.
Show
João Mesquita added a comment - Please, reopen if this is still an issue. No news from reporter after several weeks.

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    François
Vote (0)
Watch (3)

Dates

  • Created:
    Updated: