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!