23 Mar
2008
23 Mar
'08
6:54 a.m.
I have a problem with SER 2.0.0-RC1 and rtpproxy that
needs some help.
I have a PSTN gateway config and a SER box all in a 10.x.x.x address
space. Directly connected to two interfaces on the connect to a
Cisco router, which performs 1:1 NAT conversion to provide
public Internet IPs to those interfaces, one for SIP and
one for RTP. (They are separate for bandwidth, debugging
and access-list reasons.)
Another two interfaces on the SER connect to the PSTN switch,
which has separate ports for SIP and RTP traffic.
Across the Internet or direct connections to the Cisco
router are from Asterisk boxes or similar devices that
proxy all SIP/RTP data from their SIP phones.
It looks like this:
Asterisk SIP SIP SIP
Server +-----+ +-+ +------+
66.1.2.3--internet--208.4.5.6|Cisco|----10.1.1.2|S|10.2.1.1--.2|PSTN |
| 1:1 | |E| |Switch|
208.4.5.7| NAT |----10.5.1.2|R|10.6.1.1--.2|TDM |
+-----+ +-+ +------+
RTP RTP RTP
208.4.5.6 is converted to 10.1.1.2 and vice versa
208.4.5.7 is converted to 10.5.1.2 and vice versa
(Cisco command)
ip nat inside source static 10.1.1.2 208.4.5.6
ip nat inside source static 10.5.1.2 208.4.5.7
rtpproxy is in use, and has 10.5.1.2(em5) (toward Cisco) and
10.6.1.1(em4) (toward PSTN switch).
SER listens on 10.1.1.2(em1) and 10.2.1.1(em0).
Ser.cfg takes care of the small amount of SIP-related tweaking
that must be done to make SIP work:
if (dst_ip==10.1.1.2) { #Received on em1
force_send_socket("10.2.1.1"); #emit on em0
rewritehost("10.2.1.2"); #Send to PSTN Switch
$gw_ip = "10.2.1.2"; #Send to PSTN Switch
When the INVITE message finally reaches the PSTN switch, it says:
U 2008/03/23 04:05:55.780069 10.2.1.1:5060 -> 10.2.1.2:5060
INVITE sip:4097679102@10.2.1.2 SIP/2.0.
Via: SIP/2.0/UDP 10.2.1.1;branch=z9hG4bK7572.3545b131.0.
Via: SIP/2.0/UDP 66.1.2.3:5060;branch=z9hG4bK39eee695;rport=5060.
From: "VOIP TEST 1000" <sip:4697271700@66.1.2.3>;tag=as571000e7.
To: <sip:4097679102@208.4.5.6>.
Contact: <sip:4697271700@66.1.2.3>.
Call-ID: 2bf456fe3016fd6b62a1649c7cb6cd75(a)66.1.2.3.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 16.
Date: Sun, 23 Mar 2008 04:05:50 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 490.
.
v=0.
o=root 55522 55522 IN IP4 66.1.2.3.
s=session.
c=IN IP4 10.6.1.1.
t=0 0.
m=audio 35010 RTP/AVP 0 3 8 112 5 10 7 97 111 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:112 AAL2-G726-32/8000.
a=rtpmap:5 DVI4/8000.
a=rtpmap:10 L16/8000.
a=rtpmap:7 LPC/8000.
a=rtpmap:97 iLBC/8000.
a=fmtp:97 mode=30.
a=rtpmap:111 G726-32/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.
So the invite sent to the PSTN looks wonderful, correctly pointing
SIP and RTP back to the SER box.
The problem is on the Cisco side of the SER box, and shows up when the
183/200 messages are emitted by the SER. SER/rtpproxy rewrite the
c=IN IP4 line to point to 10.5.1.2, which would be fine except that
I need the public IP address 208.4.5.7 to appear in this position.
I have tried using force_rtp_proxy("flags","208.4.5.7") in the
reply_route section, and I know it is getting executed, but
nothing changes. I've tried a variety of flag combinations,
but obviously haven't tried all 720 combinations (although it feels
like I have).
I also tried fix_nated_sdp("2") by itself, with an empty
force_rtp_proxy() and a force_rtp_proxy("","208.4.5.7") and
all that did was create a "none of the above value" for c= of
10.6.1.110.5.1.2, pasting the two IP addresses together from
the rtpproxy command line, and ignoring the value right value
I'm trying to provide.
So, the question is: How do you say to SER "Here is the value
that should be used for c= on this call"? How do I set this?
For complex reasons eliminated here to make the example simple,
extending the public IP address over to the em5 interface
so it is public already is not practical. I need a fix that
changes the SDP c= value to one I will know based on whom the
distant asterisk server (or equivalent) device will be.
There may be other fields that also need fixing for RFC compliancy,
but c= being wrong is the current problem.
Thanks for suggestions.