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@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.