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.
On 08/25/2014 07:25 PM, Alex Villacís Lasso wrote:
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.
El 25/08/14 18:28, Alex Balashov escribió:
On 08/25/2014 07:25 PM, Alex Villacís Lasso wrote:
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?
El 26/08/14 12:02, Alex Villacís Lasso escribió:
El 25/08/14 18:28, Alex Balashov escribió:
On 08/25/2014 07:25 PM, Alex Villacís Lasso wrote:
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 sr-users@lists.sip-router.org 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?
On Tue, Aug 26, 2014 at 2:20 PM, Alex Villacís Lasso a_villacis@palosanto.com wrote:
El 26/08/14 12:02, Alex Villacís Lasso escribió:
El 25/08/14 18:28, Alex Balashov escribió:
On 08/25/2014 07:25 PM, Alex Villacís Lasso wrote:
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].
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 sr-users@lists.sip-router.org 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?
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
On 08/26/2014 08:56 PM, Paul Belanger wrote:
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
On 08/26/14 20:58, Alex Balashov wrote:
On 08/26/2014 08:56 PM, Paul Belanger wrote:
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
On Tue, Aug 26, 2014 at 9:21 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 08/26/14 20:58, Alex Balashov wrote:
On 08/26/2014 08:56 PM, Paul Belanger wrote:
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.
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 From: a_villacis@palosanto.com To: sr-users@lists.sip-router.org Subject: Re: [SR-Users] How do I translate rtpproxy bridge mode config to mediaproxy-ng/rtpengine?
El 25/08/14 18:28, Alex Balashov escribió:
On 08/25/2014 07:25 PM, Alex Villacís Lasso wrote:
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 sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 08/25/14 19:25, Alex Villacís Lasso wrote:
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.
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
On 08/25/14 19:25, Alex Villacís Lasso wrote:
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.
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
On Sep 15, 2014, at 1:32 PM, Richard Fuchs rfuchs@sipwise.com wrote:
On 08/25/14 19:25, Alex Villacís Lasso wrote:
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.
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
-
Alex Balashov -
Alex Villacís Lasso -
Frank Carmickle -
Kamrul Khan -
Paul Belanger -
Richard Fuchs