6 Oct
2010
6 Oct
'10
6:41 p.m.
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
6 Oct
6 Oct
6:45 p.m.
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");
--
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/
7:06 p.m.
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");
7:09 p.m.
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. :-)
--
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/
7:18 p.m.
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=mo…
Regards,
Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Shelton <stagg(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:19 p.m.
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=mo…
Regards,
Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Shelton<stagg(a)vocalcloud.com> wrote:
--
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/
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:22 p.m.
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(a)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=mo…
Regards,
Ovidiu Sas
On Wed, Oct 6, 2010 at 6:41 PM, Stagg Shelton<stagg(a)vocalcloud.com>
wrote:
--
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:24 p.m.
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/
7:29 p.m.
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(a)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/
5247
days inactive
5247
days old
8 comments
3 participants
participants (3)
-
Alex Balashov -
Ovidiu Sas -
Stagg Shelton