Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA - 10.0.201.196
OpenSER - eth0: 208.208.53.5/24 - eth1: 10.0.201.5/24
Asterisk - eth0: 65.234.34.5/24 - eth1: 10.0.201.6/24
Yes, Asterisk and OpenSER are on the same Private network currently. This is just for testing as clients were originally connecting directly to Asterisk. It will not always be the case.
I have registration working correctly.
If my SIP ATA makes an outbound call (INVITE) it appears to inform Asterisk in its SDP payload that media traffic (RTP) should be sent back to 10.0.201.5 (on eth1). Asterisk has no problem with this since it also has an IP on the 10.0.201.0/24 network. However this obviously will not always be the case. I want media (RTP) to travel back via the eth0 IP addresses.
I've tried the following:
force_rtp_proxy("", "208.208.53.5")
To hopefully force my media address to be the IP on eth0 on OpenSER. However, calls no longer succeed and I see the following in the SDP payload now:
v=0 o=- 1298429 1298429 IN IP4 10.0.201.196 s=- c=IN IP4 208.208.53.510.0.201.5 t=0 0 m=audio 3508835088 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=direction:active a=nortpproxy:yes a=nortpproxy:yes
As you can see, the info in c= has both IP's and they are not seperate by a space. This same phenomenon occurs even if I use force_rtp_proxy by itself or with any of the flags.
Normally there is just one IP address in this field it seems.
Is this a bug in force_rtp_proxy or am I doing something incorrectly?
Thanks!
Hi Ray!
On which interface is rtpproxy listening? Try starting rtpproxy with command line options to bind on 208.208.53.5.
This way, force_rtp_proxy should insert the 208... IP address into the SDP.
regards, klaus
Ray Van Dolson wrote:
Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA
- 10.0.201.196
OpenSER
- eth0: 208.208.53.5/24
- eth1: 10.0.201.5/24
Asterisk
- eth0: 65.234.34.5/24
- eth1: 10.0.201.6/24
Yes, Asterisk and OpenSER are on the same Private network currently. This is just for testing as clients were originally connecting directly to Asterisk. It will not always be the case.
I have registration working correctly.
If my SIP ATA makes an outbound call (INVITE) it appears to inform Asterisk in its SDP payload that media traffic (RTP) should be sent back to 10.0.201.5 (on eth1). Asterisk has no problem with this since it also has an IP on the 10.0.201.0/24 network. However this obviously will not always be the case. I want media (RTP) to travel back via the eth0 IP addresses.
I've tried the following:
force_rtp_proxy("", "208.208.53.5")
To hopefully force my media address to be the IP on eth0 on OpenSER. However, calls no longer succeed and I see the following in the SDP payload now:
v=0 o=- 1298429 1298429 IN IP4 10.0.201.196 s=- c=IN IP4 208.208.53.510.0.201.5 t=0 0 m=audio 3508835088 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=direction:active a=nortpproxy:yes a=nortpproxy:yes
As you can see, the info in c= has both IP's and they are not seperate by a space. This same phenomenon occurs even if I use force_rtp_proxy by itself or with any of the flags.
Normally there is just one IP address in this field it seems.
Is this a bug in force_rtp_proxy or am I doing something incorrectly?
Thanks!
On Wed, Aug 03, 2005 at 12:15:24AM +0200, Klaus Darilion wrote:
Hi Ray!
On which interface is rtpproxy listening? Try starting rtpproxy with command line options to bind on 208.208.53.5.
This way, force_rtp_proxy should insert the 208... IP address into the SDP.
Thanks Klaus... getting closer--I think. I wonder if there is any way to run two instances of rtpproxy? Voice packets are halfway flowing correctly, but not quite:
Outbound call from SIP ATA is established.
Asterisk shows RTP data going from 65.234.34.5 -> 208.208.53.5
However a tcpdump on OpenSER eth1 shows RTP data with source IP 208.208.53.5 -> 10.0.201.196. The source IP should be being rewritten as 10.0.201.5, but it is not. In addition I don't get any voice data back from the SIP ATA leading me to believe the force_rtp_proxy is somehow passing the public IP address back to my SIP ATA device (which is unroutable).
Must be a way to handle this both ways. My config file is getting pretty crazy so I may wipe everything out and start from scratch and try to keep it simple.
Ray
Ray Van Dolson wrote:
Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA
- 10.0.201.196
OpenSER
- eth0: 208.208.53.5/24
- eth1: 10.0.201.5/24
Asterisk
- eth0: 65.234.34.5/24
- eth1: 10.0.201.6/24
However a tcpdump on OpenSER eth1 shows RTP data with source IP 208.208.53.5 -> 10.0.201.196. The source IP should be being rewritten as 10.0.201.5, but it is not. In addition I don't get any voice data back from the SIP ATA leading me to believe the force_rtp_proxy is somehow passing the public IP address back to my SIP ATA device (which is unroutable).
One more follow up on this. It appears that when the call is answererd and Asterisk sends back its 200 OK message to the ATA, the c= is set to 208.208.53.5.
c= IN IP4 208.208.53.5
My (fairly simple) openser.cfg file is located here:
http://webdev.digitalpath.net/~rayvd/voice/openser.cfg
I am starting rtpproxy with the following command-line:
rtpproxy -l 208.208.53.5/10.0.201.5 -t 0xb8
SIP ATA devices are completely private. They can only talk to other devices on the same network (no Internet NAT being done).
Ray
Ray Van Dolson wrote:
Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA
- 10.0.201.196
OpenSER
- eth0: 208.208.53.5/24
- eth1: 10.0.201.5/24
Asterisk
- eth0: 65.234.34.5/24
- eth1: 10.0.201.6/24
Hi Ray,
for bridging between two non-routable networks, you have an example about how to configure nathelper and rtpproxy : sip-server/modules/nathelper/examples/alg.cfg (IMPORTANT: in the script header there is a note about how to start rtpptroxy in bridging mode)
you might find it very useful.
regards, Bogdan
Ray Van Dolson wrote:
However a tcpdump on OpenSER eth1 shows RTP data with source IP 208.208.53.5 -> 10.0.201.196. The source IP should be being rewritten as 10.0.201.5, but it is not. In addition I don't get any voice data back from the SIP ATA leading me to believe the force_rtp_proxy is somehow passing the public IP address back to my SIP ATA device (which is unroutable).
One more follow up on this. It appears that when the call is answererd and Asterisk sends back its 200 OK message to the ATA, the c= is set to 208.208.53.5.
c= IN IP4 208.208.53.5
My (fairly simple) openser.cfg file is located here:
http://webdev.digitalpath.net/~rayvd/voice/openser.cfg
I am starting rtpproxy with the following command-line:
rtpproxy -l 208.208.53.5/10.0.201.5 -t 0xb8
SIP ATA devices are completely private. They can only talk to other devices on the same network (no Internet NAT being done).
Ray
Ray Van Dolson wrote:
Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA
- 10.0.201.196
OpenSER
- eth0: 208.208.53.5/24
- eth1: 10.0.201.5/24
Asterisk
- eth0: 65.234.34.5/24
- eth1: 10.0.201.6/24
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Thanks Bogdan, that helped get me going in the right direction. I had no idea you could provide multiple flags to force_rtp_proxy, and didn't really understand how the argument related to the IP's passed to rtpproxy. In addition rtpproxy -h wasn't *too* informative, but looking at the source helped me figure out the meanings of various flags.
My working config file is here:
http://webdev.digitalpath.net/~rayvd/voice/openser.cfg
Comments on problems appreciated.
I'm not completely clear why the calls to force_rtp_proxy included both the I and the E (just in reversed order depending on context). I haven't tried without to see if they are really necessary.
In any case, things appear to be working now!
Ray
On Wed, Aug 03, 2005 at 12:11:25PM +0300, Bogdan-Andrei Iancu wrote:
Hi Ray,
for bridging between two non-routable networks, you have an example about how to configure nathelper and rtpproxy : sip-server/modules/nathelper/examples/alg.cfg (IMPORTANT: in the script header there is a note about how to start rtpptroxy in bridging mode)
you might find it very useful.
Hi Ray,
double-check if you do not call twice force_rtp_proxy() for the INVITE - this might be the reason for the double IP in "c=" - as hint: notice you have the "a=nortpproxy:yes" twice!
regards, bogdan
Ray Van Dolson wrote:
Thanks for the help earlier Bogdan.
I've gotten things working for the most part, but am having a problem with the force_rtp_proxy function.
Once again, here is my setup:
SIP ATA
- 10.0.201.196
OpenSER
- eth0: 208.208.53.5/24
- eth1: 10.0.201.5/24
Asterisk
- eth0: 65.234.34.5/24
- eth1: 10.0.201.6/24
Yes, Asterisk and OpenSER are on the same Private network currently. This is just for testing as clients were originally connecting directly to Asterisk. It will not always be the case.
I have registration working correctly.
If my SIP ATA makes an outbound call (INVITE) it appears to inform Asterisk in its SDP payload that media traffic (RTP) should be sent back to 10.0.201.5 (on eth1). Asterisk has no problem with this since it also has an IP on the 10.0.201.0/24 network. However this obviously will not always be the case. I want media (RTP) to travel back via the eth0 IP addresses.
I've tried the following:
force_rtp_proxy("", "208.208.53.5")
To hopefully force my media address to be the IP on eth0 on OpenSER. However, calls no longer succeed and I see the following in the SDP payload now:
v=0 o=- 1298429 1298429 IN IP4 10.0.201.196 s=- c=IN IP4 208.208.53.510.0.201.5 t=0 0 m=audio 3508835088 RTP/AVP 0 2 4 8 18 96 97 98 100 101 a=rtpmap:0 PCMU/8000 a=rtpmap:2 G726-32/8000 a=rtpmap:4 G723/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729a/8000 a=rtpmap:96 G726-40/8000 a=rtpmap:97 G726-24/8000 a=rtpmap:98 G726-16/8000 a=rtpmap:100 NSE/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:30 a=sendrecv a=direction:active a=nortpproxy:yes a=nortpproxy:yes
As you can see, the info in c= has both IP's and they are not seperate by a space. This same phenomenon occurs even if I use force_rtp_proxy by itself or with any of the flags.
Normally there is just one IP address in this field it seems.
Is this a bug in force_rtp_proxy or am I doing something incorrectly?
Thanks!
-
Bogdan-Andrei Iancu -
Klaus Darilion -
Ray Van Dolson