rtpengine as drop-in replacement for rtpproxy

[Monideth Pen]

Hi,

I am evaluating whether rtpengine can be used as a replacement for rtpproxy. As part of the evaluation I want to test rtpengine as a drop-in replacement of a existing and working opensips 2.4 and rtpproxy 2.2.0 setup.

I understand that, in theory, this could be achieved by using the "--listen-udp" option which will put rtpengine in to 'legacy' mode and it should support rtpproxy protocol requests on the "--listen-udp" port.

However, we are finding that rtpengine is returning a port of 0, which opensips treats as an error, and so the SDP mapping is not done.

For example, in the rtpengine logs, I see something like:

----

[core] Returning to SIP proxy: 23792_8980_204 0 <IP> 4

-----

What can I check and look at to determine why rtpengine is returning a port of 0. What could cause it to do this?

Thank you.

[Richard Fuchs]

The first step should be to enable debug logging in rtpengine and see what else you can see in the log. Post the log here if you don't see an obvious error.

These legacy protocols are barely maintained and there's no testing for them in place, so it wouldn't be surprising to see a regression there. I've actually considered removing support for these protocols because of that. In general I suggest switching to the native protocol, which OpenSIPS also supports.

Cheers

[Monideth Pen]

Hi Richard,

(Sorry, resent to group conversation, as the first reply went to your personal email)

Thanks for the quick response.

This was just to try to get a quick test without having to change our opensips config and logic.

I have enabled debug logging for rtpengine - here is example of when I make in outbound (from internal to external) call - I've sanitised and coloured in the IPs to help show what they are:

rtpengine[22623]: INFO: [control] Got valid command from udp:<opensips mgmt IP>:41903: 23943_3886_66 UEIc8,0,101 88c455f81d154c58aea0197729aa0940 <local endpoint IP> 4036 01cf7e6ad85147c09d51785209754ff5;1
rtpengine[22623]: NOTICE: [88c455f81d154c58aea0197729aa0940]: [core] Creating new call
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [core] Subscribing '01cf7e6ad85147c09d51785209754ff5' to ''
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [core] Subscribing '' to '01cf7e6ad85147c09d51785209754ff5'
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Updating codecs for offerer 01cf7e6ad85147c09d51785209754ff5 #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Updating codecs for answerer  #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Updating supplemental codecs for  #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Setting up codec handlers for  #1 -> 01cf7e6ad85147c09d51785209754ff5 #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Updating supplemental codecs for  #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [codec] Setting up codec handlers for  #1 -> 01cf7e6ad85147c09d51785209754ff5 #1
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [core] set FILLED flag for stream, local    <internal IP>:0   remote   <remote endpoint IP> :4036
rtpengine[22623]: DEBUG: [88c455f81d154c58aea0197729aa0940]: [core] set FILLED flag for stream, local    <internal IP>:0   remote 1   <remote endpoint IP> :4037

rtpengine[22623]: INFO: [88c455f81d154c58aea0197729aa0940]: [core] Returning to SIP proxy: 23943_3886_66 0 <external IP>  4

You can see where it only allocates a 0 (zero) port when it returns back the U (Update) query results to opensips.

In the rtpengine config I have set the interfaces:

interface = external/<external IP>;internal/<internal IP>

I hope this information is useful for you.

(Note that our currently working opensips config/logic currently sends "EI" for the ordering in the Update request - which I think is the opposite of what it should actually be, but we have compensated for that in our currently working rtpproxy config, and for this rtpengine config too).

Thank you.

[Monideth Pen]

Sorry, I was meant to highlight the most important bit of the the last log line!:

rtpengine[22623]: INFO: [88c455f81d154c58aea0197729aa0940]: [core] Returning to SIP proxy: 23943_3886_66 0 <external IP>  4

Thank you.

[Richard Fuchs]

Found the problem. Looks like a regression from a previous rework. The fix is submitted here: https://github.com/sipwise/rtpengine/commit/302f7d64570a3ddf585a3f39261c4f58d732cc85

(Also backported to older affected branches)

Cheers

--
You received this message because you are subscribed to the Google Groups "rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/526acab2-c44b-4518-86ef-cdca46fde502n%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Monideth Pen]

Hi Richard,

Wow, that is amazing!

I'll get it tested - probably won't be able to do that until Monday now - and will report back.

Thank you so much for taking the time to look into and fixing this issue!

[Monideth Pen]

Hi Richard,

I was able to test a build with the fixes and I can confirm that it has resolved the issue and I was able to get it working as a drop-in replacement for rtpproxy.

We have only briefly tested it in user-space mode and will not proceed with getting the kernel-space mode working.

Thank you once again for your support.