[SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

[Alex Villací­s Lasso]

I have a rtpproxy configuration that spawns several rtpproxy instances, using bridge mode. An example is shown below:

/usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 10000 -M 20000

Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .

Now I want to migrate to rtpengine with the rtpproxy-ng module in kamailio. However, I do not find an equivalent to bridge mode in the rtpengine command-line parameters. I see the --ip=IP parameter, but the source code expects a single IP address, and
cannot be specified more than once. The closest I see is the --advertised-ip=IP parameter, but I am not sure that it will do what I need.

[Alex Balashov]

Post by Alex Villací­s Lasso
However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.

Bridging mode of this type is not supported by rtpengine.

[Alex Villací­s Lasso]

Post by Alex Balashov

Post by Alex Villací­s Lasso
However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.

Bridging mode of this type is not supported by rtpengine.

If this is true, then mediaproxy-ng/rtpengine should not be announced in the Kamailio documentation (http://www.kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html) as a "drop-in" replacement. At the very least, this requires a documentation fix.

How would somebody implement the following scenario using rtpproxy or mediaproxy-ng/rtpengine ?

- Server with 2 or more interfaces, at least one of which is public, and at least one of which is private (LAN)
- Public interface runs webserver that publishes web phone (SIP.js or similar) for websocket
- Webserver runs kamailio with access to both public and private interfaces
- Websocket managed by kamailio, for SIP.js signaling
- Private interface gives access to LAN where at least one traditional SIP client (UDP port 5060) registers with kamailio
- Phone call initiated through websocket should contact SIP client in private LAN after proper authentication.

Can this be done at all with current technologies? How?

[Alex Villací­s Lasso]

Post by Alex Villací­s Lasso

Post by Alex Balashov

Post by Alex Villací­s Lasso
However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.

Bridging mode of this type is not supported by rtpengine.

If this is true, then mediaproxy-ng/rtpengine should not be announced in the Kamailio documentation (http://www.kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html) as a "drop-in" replacement. At the very least, this requires a documentation fix.
How would somebody implement the following scenario using rtpproxy or mediaproxy-ng/rtpengine ?
- Server with 2 or more interfaces, at least one of which is public, and at least one of which is private (LAN)
- Public interface runs webserver that publishes web phone (SIP.js or similar) for websocket
- Webserver runs kamailio with access to both public and private interfaces
- Websocket managed by kamailio, for SIP.js signaling
- Private interface gives access to LAN where at least one traditional SIP client (UDP port 5060) registers with kamailio
- Phone call initiated through websocket should contact SIP client in private LAN after proper authentication.
Can this be done at all with current technologies? How?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Just to clarify, the above scenario is not exactly what I want to implement. What I want to implement is interconnection between Kamailio (managing websockets) and Asterisk (which, by itself, could run websockets but is currently isolated).

The scenario is a multihomed server that runs asterisk in localhost only, and uses kamailio to simulate multiple domains, and to provide SIP presence support. Currently, rtpproxy works correctly (in traditional SIP) to bridge the RTP packets from localhost
to each of the interfaces. The question is: can it be used to bridge DTLS-SRTP, without touching the (encrypted) payloads, and delegate the decryption to asterisk itself?

[Paul Belanger]

On Tue, Aug 26, 2014 at 2:20 PM, Alex Villací­s Lasso

Post by Alex Villací­s Lasso

Post by Alex Villací­s Lasso

Post by Alex Balashov

Post by Alex Villací­s Lasso
However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.

Bridging mode of this type is not supported by rtpengine.

If this is true, then mediaproxy-ng/rtpengine should not be announced in
the Kamailio documentation
(http://www.kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html) as a
"drop-in" replacement. At the very least, this requires a documentation fix.

I'd agree 'drop-in' replacement is not correct. I ran into the same
issues as you. Current there is no bridge-mode in rtpengine, I point
you to an open issue about it [1].

Post by Alex Villací­s Lasso

Post by Alex Villací­s Lasso
How would somebody implement the following scenario using rtpproxy or
mediaproxy-ng/rtpengine ?
- Server with 2 or more interfaces, at least one of which is public, and
at least one of which is private (LAN)
- Public interface runs webserver that publishes web phone (SIP.js or
similar) for websocket
- Webserver runs kamailio with access to both public and private interfaces
- Websocket managed by kamailio, for SIP.js signaling
- Private interface gives access to LAN where at least one traditional SIP
client (UDP port 5060) registers with kamailio
- Phone call initiated through websocket should contact SIP client in
private LAN after proper authentication.
Can this be done at all with current technologies? How?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Just to clarify, the above scenario is not exactly what I want to implement.
What I want to implement is interconnection between Kamailio (managing
websockets) and Asterisk (which, by itself, could run websockets but is
currently isolated).
The scenario is a multihomed server that runs asterisk in localhost only,
and uses kamailio to simulate multiple domains, and to provide SIP presence
support. Currently, rtpproxy works correctly (in traditional SIP) to bridge
can it be used to bridge DTLS-SRTP, without touching the (encrypted)
payloads, and delegate the decryption to asterisk itself?

While my setup is not the same as yours, the fix would be to bind
asterisk to the same interface as kamailio (different port for SIP),
then simple allow rtpengine to relay to the single interface.

For the moment, I had to rework my firewall rule sets to allow
asterisk (rtp) on the public interface.

[1] https://github.com/sipwise/rtpengine/issues/4

[Alex Balashov]

Post by Paul Belanger
I'd agree 'drop-in' replacement is not correct. I ran into the same
issues as you. Current there is no bridge-mode in rtpengine, I point
you to an open issue about it [1].

I think the idea behind the formulation of "drop-in replacement" is that
the module interface functions are compatible with the standard
'rtpproxy' module, so no config changes are required to make it work.

It doesn't mean that all the old features exist. It means that they are
stubbed out in such a manner as to not invalidate the existing config.

Even then, that's not entirely true, given the 'rtpengine' nomenclature
change recently.

-- Alex

[Richard Fuchs]

Post by Alex Balashov

Post by Paul Belanger
I'd agree 'drop-in' replacement is not correct. I ran into the same
issues as you. Current there is no bridge-mode in rtpengine, I point
you to an open issue about it [1].

I think the idea behind the formulation of "drop-in replacement" is that
the module interface functions are compatible with the standard
'rtpproxy' module, so no config changes are required to make it work.
It doesn't mean that all the old features exist. It means that they are
stubbed out in such a manner as to not invalidate the existing config.
Even then, that's not entirely true, given the 'rtpengine' nomenclature
change recently.

Correct, the "drop-in replacement" wording was related to the older
module rtpproxy-ng. The newer rtpengine module isn't 100% compatible any
more, so the docs should probably be changed.

cheers

[Paul Belanger]

Post by Richard Fuchs

Post by Alex Balashov

Post by Paul Belanger
I'd agree 'drop-in' replacement is not correct. I ran into the same
issues as you. Current there is no bridge-mode in rtpengine, I point
you to an open issue about it [1].

I think the idea behind the formulation of "drop-in replacement" is that
the module interface functions are compatible with the standard
'rtpproxy' module, so no config changes are required to make it work.
It doesn't mean that all the old features exist. It means that they are
stubbed out in such a manner as to not invalidate the existing config.
Even then, that's not entirely true, given the 'rtpengine' nomenclature
change recently.

Correct, the "drop-in replacement" wording was related to the older
module rtpproxy-ng. The newer rtpengine module isn't 100% compatible any
more, so the docs should probably be changed.

Ya, I should have been more specific. Not 100% feature compatible.

[Kamrul Khan]

Hi,
We have a Kamalio a configuration that forwards calls to a freeswitch server (adding record-route). The SIP signaling becomes successful till Kamailio receives 200 OK with session description from our carrier. After kamailio forwards the 200 OK with session description to Freeswitch, Kamailio drops all the ACK and BYE coming from freeswitch. From Kamailio log we found it says,
Aug 26 18:20:15 tyran /usr/sbin/kamailio[17980]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:17 tyran /usr/sbin/kamailio[17979]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:21 tyran /usr/sbin/kamailio[17979]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:25 tyran /usr/sbin/kamailio[17980]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:29 tyran /usr/sbin/kamailio[17980]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:33 tyran /usr/sbin/kamailio[17979]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:37 tyran /usr/sbin/kamailio[17980]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:41 tyran /usr/sbin/kamailio[17979]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain tableAug 26 18:20:45 tyran /usr/sbin/kamailio[17980]: ERROR: <script>: 1.2.3.4 BYE sip:1.2.3.4:5063;transport=udp;lr=on -- domain "4.3.2.1" is not found in domain table
We are not sure why it can send all the other messages and cant find the domain only for ACK and BYE. Please help. Thanks in advanced.

Date: Tue, 26 Aug 2014 12:02:50 -0500
Subject: Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?

Post by Alex Balashov

Post by Alex Villací­s Lasso
However, I do not find an equivalent to bridge mode in the rtpengine
command-line parameters.

Bridging mode of this type is not supported by rtpengine.

If this is true, then mediaproxy-ng/rtpengine should not be announced in the Kamailio documentation (http://www.kamailio.org/docs/modules/4.1.x/modules/rtpproxy-ng.html) as a "drop-in" replacement. At the very least, this requires a documentation fix.
How would somebody implement the following scenario using rtpproxy or mediaproxy-ng/rtpengine ?
- Server with 2 or more interfaces, at least one of which is public, and at least one of which is private (LAN)
- Public interface runs webserver that publishes web phone (SIP.js or similar) for websocket
- Webserver runs kamailio with access to both public and private interfaces
- Websocket managed by kamailio, for SIP.js signaling
- Private interface gives access to LAN where at least one traditional SIP client (UDP port 5060) registers with kamailio
- Phone call initiated through websocket should contact SIP client in private LAN after proper authentication.
Can this be done at all with current technologies? How?
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Richard Fuchs]

Post by Alex Villací­s Lasso
I have a rtpproxy configuration that spawns several rtpproxy instances,
/usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s
udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 10000 -M 20000
Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .
Now I want to migrate to rtpengine with the rtpproxy-ng module in
kamailio. However, I do not find an equivalent to bridge mode in the
rtpengine command-line parameters. I see the --ip=IP parameter, but the
source code expects a single IP address, and cannot be specified more
than once. The closest I see is the --advertised-ip=IP parameter, but I
am not sure that it will do what I need.

Depending on your network setup, you should be able to allow your
private IP networks to communicate with the public address of the media
proxy by adding a network route in the right place(s). Another possible
solution could be to use the media-address= option. Certain iptables
rules (assuming you're on Linux) such as SNAT might also be helpful, or
a combination of several of these mechanisms.

cheers

[Richard Fuchs]

Post by Alex Villací­s Lasso
I have a rtpproxy configuration that spawns several rtpproxy instances,
/usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s
udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 10000 -M 20000
Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .
Now I want to migrate to rtpengine with the rtpproxy-ng module in
kamailio. However, I do not find an equivalent to bridge mode in the
rtpengine command-line parameters. I see the --ip=IP parameter, but the
source code expects a single IP address, and cannot be specified more
than once. The closest I see is the --advertised-ip=IP parameter, but I
am not sure that it will do what I need.

Just a quick note to you and anyone else who has asked for this: With
the latest version of rtpengine (git master), bridging between multiple
local interfaces is fully supported.

cheers

[Frank Carmickle]

Post by Richard Fuchs

Post by Alex Villací­s Lasso
I have a rtpproxy configuration that spawns several rtpproxy instances,
/usr/bin/rtpproxy -p /var/run/rtpproxy.pid-7723 -u rtpproxy -s
udp:127.0.0.1 7723 192.168.2.18/127.0.0.1 -m 10000 -M 20000
Here, rtpproxy bridges between 192.168.2.18 and 127.0.0.1 .
Now I want to migrate to rtpengine with the rtpproxy-ng module in
kamailio. However, I do not find an equivalent to bridge mode in the
rtpengine command-line parameters. I see the --ip=IP parameter, but the
source code expects a single IP address, and cannot be specified more
than once. The closest I see is the --advertised-ip=IP parameter, but I
am not sure that it will do what I need.

Just a quick note to you and anyone else who has asked for this: With
the latest version of rtpengine (git master), bridging between multiple
local interfaces is fully supported.

Thank you Richard!

--FC