I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Thanks Stagg
On 10/06/2010 06:41 PM, Stagg Shelton wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Are you invoking rtpproxy in bridging mode?
If so, try one of:
force_rtp_proxy("ocfaie");
or the opposite direction:
force_rtp_proxy("ocfaei");
Thanks Alex.
Early tests after your change seem to indicate that fixed the problem. I'm looking at the docs with this new perspective, and when we read the description of the i flag and the e flag it seems to suggest that they are used independently. Nothing jumped out at us to use them together in the order that the packet was flowing from the outside to the inside. Thanks for your quick insight on this, i'm not sure I would have come up with it.
Stagg
On 10/6/10 6:45 PM, Alex Balashov wrote:
On 10/06/2010 06:41 PM, Stagg Shelton wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Are you invoking rtpproxy in bridging mode?
If so, try one of:
force_rtp_proxy("ocfaie");
or the opposite direction:
force_rtp_proxy("ocfaei");
On 10/06/2010 07:06 PM, Stagg Shelton wrote:
Early tests after your change seem to indicate that fixed the problem. I'm looking at the docs with this new perspective, and when we read the description of the i flag and the e flag it seems to suggest that they are used independently. Nothing jumped out at us to use them together in the order that the packet was flowing from the outside to the inside. Thanks for your quick insight on this, i'm not sure I would have come up with it.
The docs are completely unedifying on this point, so I don't blame you.
I can't take credit for the insight; it was provided by Daniel at some point on this list, and has remained in our trivia database. :-)
You post reminded me that I should update the examples on the repo (which I just did). It is better to use the new rtpproxy_offer/rtpproxy_answer functions. For a quick example, please check: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=mod...
Regards, Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Shelton stagg@vocalcloud.com wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Thanks Stagg
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
I assume that means rtpproxy_answer|offer actually work now. :-)
Last time there was a conversation about using them, in fall 2009, we concluded that they don't work and went back to using force_rtp_proxy().
On 10/06/2010 07:18 PM, Ovidiu Sas wrote:
You post reminded me that I should update the examples on the repo (which I just did). It is better to use the new rtpproxy_offer/rtpproxy_answer functions. For a quick example, please check: http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=mod...
Regards, Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Sheltonstagg@vocalcloud.com wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Thanks Stagg
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
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
They work ok in my setup. The plan is to remove force_rtp_proxy in 3.2.
Regards, Ovidiu Sas
On Wed, Oct 6, 2010 at 7:19 PM, Alex Balashov abalashov@evaristesys.com wrote:
I assume that means rtpproxy_answer|offer actually work now. :-)
Last time there was a conversation about using them, in fall 2009, we concluded that they don't work and went back to using force_rtp_proxy().
On 10/06/2010 07:18 PM, Ovidiu Sas wrote:
You post reminded me that I should update the examples on the repo (which I just did). It is better to use the new rtpproxy_offer/rtpproxy_answer functions. For a quick example, please check:
http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=blob_plain;f=mod...
Regards, Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Sheltonstagg@vocalcloud.com wrote:
I'm working on a setup where we have rtpproxy on a machine with eth0 IP 10.10.5.141/19 and eth1 IP 10.10.10.78/24. When using force_rtp_proxy("","10.10.5.141"); the connection information (c) field in the SDP is not being set to the ip 10.10.5.141 It is instead being set to 10.10.10.78
We are starting to run out of ideas on getting the proper contact address into the sdp based on call source signaling ip. Does anyone have any ideas what the problem could be?
Thanks Stagg
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
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
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
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 10/06/2010 07:22 PM, Ovidiu Sas wrote:
They work ok in my setup. The plan is to remove force_rtp_proxy in 3.2.
A wholeheartedly palatable goal -- if they work. :-)
IIRC, the issue we had was with trying to use them with the same richness and diversity of flags that force_rtp_proxy() has. Despite allegations of compatibility, they didn't all work.
They are all wrappers around the same embedded function. Don't know what was the issue that you encounter then, but please try now and report any issues. The new rtpproxy module is using now the core sdp parser and it is way easier to track down any potential issues. Also, multipart content should work properly now (as opposed to previous versions < 3.1).
Regards, Ovidiu Sas
On Wed, Oct 6, 2010 at 7:24 PM, Alex Balashov abalashov@evaristesys.com wrote:
On 10/06/2010 07:22 PM, Ovidiu Sas wrote:
They work ok in my setup. The plan is to remove force_rtp_proxy in 3.2.
A wholeheartedly palatable goal -- if they work. :-)
IIRC, the issue we had was with trying to use them with the same richness and diversity of flags that force_rtp_proxy() has. Despite allegations of compatibility, they didn't all work.
-- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
-
Alex Balashov -
Ovidiu Sas -
Stagg Shelton