Caller changes origination udp port in the middle of the call

[mrsanvicente]

Hello there,

I have a setup running bridge configuration with work fine. But i have some calls getting no audio after a while.

I captured a trace and followedup up udp streams, and noticed that after 12 - 13 mins, the caller ( softphone) changes the source udp port, with no notification. Is this a normal behavior?
Should the rtp sesssion update / reply to the media source port?

Example:
The source udp port from the caller changes from 30556 to startron without any notice. Should RTPPROXY update it?

Apr 24 10:45:52 181-15-35 rtpproxy[1994]: INFO:17cede00e63616c6c3c2075bb@x.x.x.x:rtpp_command_ul_handle:493: lookup on ports 43002/43088, session timer restarted
Apr 24 10:45:53 181-15-35 rtpproxy[1994]: INFO:17cede00e63616c6c3c2075bb@x.x.x.x:rtpp_command_ul_handle:493: lookup on ports 43002/43088, session timer restarted

Capturing traffic:

32954/43088

575 2.869774194 x.130.55.153 -> x.x.15.35 UDP 216 Source port: 30556 Destination port: 43088
576 2.870557402 10.205.4.72 -> 10.205.4.70 UDP 216 Source port: 32954 Destination port: 56022
577 2.880036359 10.205.4.70 -> 10.205.4.72 UDP 216 Source port: 56022 Destination port: 32954
578 2.880556797 x.x.15.35 -> x.130.55.153 UDP 216 Source port: 43088 Destination port: 30556

After 12 -13 mins

669 3.392016613 x.130.55.153 -> x.x.15.35 UDP 216 Source port: startron Destination port: 43088
670 3.392346246 10.205.4.72 -> 10.205.4.70 UDP 216 Source port: 32954 Destination port: 56022
671 3.402140502 10.205.4.70 -> 10.205.4.72 UDP 216 Source port: 56022 Destination port: 32954
672 3.402323698 x.x.15.35 -> x.130.55.153 UDP 216 Source port: 43088 Destination port: 30556

Thank you

[sobomax]

Hi Mario, yes, this is not a normal behavior and of course SIP mandates the softphone to update session info in such situation by issuing proper re-INVITE. The best way to deal with it is to report back to softphone developers and persuade them to fix it.

There is no feature in the RTPproxy currently to workaround this broken behaviour, however if you can recompile RTPproxy then you can try setting UPDATE_WINDOW, which governs amount of time RTPproxy would accept and re-latch RTP after initial INVITE or subsequent re-INVITE, from its stock value of 10 seconds to some much larger value, say 1 hour (i.e. 3600 seconds) or more. Then if the IP changes, the proxy would just take IP of the first RTP packet from new IP and update its destination accortingly. The setting is as below:

src/rtpp_defines.h:#define      UPDATE_WINDOW   10.0    /* in seconds */

Let me know if it helps, I'll close off the ticket. Thanks!

[mrsanvicente]

Hello Maksym, Thank you for the workaround, i will try it shortly! Cheers Mario San Vicente

…

El 20 may 2021, a la(s) 13:20, Maksym Sobolyev ***@***.***> escribió:  Hi Mario, yes, this is not a normal behavior and of course SIP mandates the softphone to update session info in such situation by issuing proper re-INVITE. The best way to deal with it is to report back to softphone developers and persuade them to fix it. There is no feature in the RTPproxy currently to workaround this broken behaviour, however if you can recompile RTPproxy then you can try setting UPDATE_WINDOW, which governs amount of time RTPproxy would accept and re-latch RTP after initial INVITE or subsequent re-INVITE, from its stock value of 10 seconds to some much larger value, say 1 hour (i.e. 3600 seconds) or more. Then if the IP changes, the proxy would just take IP of the first RTP packet from new IP and update its destination accortingly. The setting is as below: src/rtpp_defines.h:#define UPDATE_WINDOW 10.0 /* in seconds */ Let me know if it helps, I'll close off the ticket. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mrsanvicente]

Hello Maksym, Finally i recompiled but the service is not coming up, i got the following error: git submodule update --init --recursive ./configure make make install /etc/init.d/rtpproxy start Jul 13 15:47:42 localhost.localdomain systemd[1]: Starting Kernel based rtp proxy... Jul 13 15:47:42 localhost.localdomain rtpproxy[25151]: /usr/local/bin/rtpproxy: error while loading shared libraries: libelperiodic.so.1: cannot open shared object... directory Jul 13 15:47:42 localhost.localdomain systemd[1]: rtpproxy.service: control process exited, code=exited status=127 Jul 13 15:47:42 localhost.localdomain systemd[1]: Failed to start Kernel based rtp proxy. Jul 13 15:47:42 localhost.localdomain systemd[1]: Unit rtpproxy.service entered failed state. Not coming up after it was working fine.... any idea? Thanks

…

On Tue, May 25, 2021 at 9:58 PM mrsanvicente ***@***.***> wrote: Hello Maksym, Thank you for the workaround, i will try it shortly! Cheers Mario San Vicente El 20 may 2021, a la(s) 13:20, Maksym Sobolyev ***@***.***> escribió:  Hi Mario, yes, this is not a normal behavior and of course SIP mandates the softphone to update session info in such situation by issuing proper re-INVITE. The best way to deal with it is to report back to softphone developers and persuade them to fix it. There is no feature in the RTPproxy currently to workaround this broken behaviour, however if you can recompile RTPproxy then you can try setting UPDATE_WINDOW, which governs amount of time RTPproxy would accept and re-latch RTP after initial INVITE or subsequent re-INVITE, from its stock value of 10 seconds to some much larger value, say 1 hour (i.e. 3600 seconds) or more. Then if the IP changes, the proxy would just take IP of the first RTP packet from new IP and update its destination accortingly. The setting is as below: src/rtpp_defines.h:#define UPDATE_WINDOW 10.0 /* in seconds */ Let me know if it helps, I'll close off the ticket. Thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#119 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABM4J2YCR44TYVWJCFZHYJTTOVHGLANCNFSM43TDG34Q> .

-- Mario San Vicente Cheers!

[mrsanvicente]

Hello,

Finally solved:

To solve:

/usr/local/bin/rtpproxy: error while loading shared libraries: libelperiodic.so.1: cannot open shared object... directory

We should add the PATH to $LD_LIBRARY_PATH:

This ways works:

create a new file in /etc/ld.so.conf.d/ like /etc/ld.so.conf.d/usrlocal.conf and add the path:

/usr/local/lib

Then just run ldconfig -v as root and that's it.