Having abandoned from mediaproxy (which could not cope with a network setup with two or more interfaces), I switched to rtpproxy, but find that it also is not doing the right thing, although it gets closer that mediaproxy does.
Perhaps someone will know what the missing piece of this is.
To recap, we have three networks connected to the SER+rtpproxy server:
192.168.200.x/24 Connects to various SIP phones and Asterisk server(s). Can be thought to eventually be the network where the SIP clients will all be. Our players in this lab setup are: 192.168.200.10 An Asterisk server 192.168.200.20 A Linksys SIP phone - (SIP+RTP for phone goes via Asterisk server so you won't see this addr at SER server) 192.168.200.30 an interface on the SER server (re2)
10.9.193.132/28 Connects to the various SIP ports on a Class 5 PSTN switch. Only SIP packets pass on this network, eg these can't handle RTP packets. Here, our visible devices are: 10.9.193.130 The active PSTN switch SIP signaling port. 10.9.193.135 An interface on the SER server (re1)
10.9.193.142/29 Connects to the bearer/voice ports on a Class 5 PSTN switch. These are isolated ports, eg, all they do is RTP packets and no SIP packets. The devices here: 10.9.193.146 The active PSTN switch voice bearer port. 10.9.193.148 An interface on the SER server (re0)
NONE of these networks can physically see the other nor router traffic, except for what passes through either SER or rtpproxy/mediaproxy. This isolation is intentional and needed because the PSTN switch has no built-in protection against unexpected/unwanted IP traffic.
Of the three networks, only two handle RTP/bearer data, and only two handle SIP data.
----------------------------------------------------------------------------
What happens (or doesn't happen):
The symptom is that someone (probably rtpproxy) isn't re-writting the correct IP address into the SDP payload emitted by SER, and so the calling party (or PSTN switch party) is editing in an unreachable IP address to send bearer traffic to. So rtpproxy never gets going and you have no two-way audio, although you can see audio packets being emitted by both parties, one hopelessly mis-addresed, and the others audio reaching the SER/rtpproxy server, but apparently not allowed to pass until an audio packet from the other party arrives, which will not be happening.
In addition, rtpproxy doesn't listen for RTP packets on both interfaces, so one side of the conversation is always inaccessible, and since both sides must be able to send at least one audio packet for the proxy process to begin, no audio is passed in either direction.
----------------------------------------------------------------------------
A sample call and the SIP messages:
1. The Asterisk server contacts the SER server with the INVITE. It says the audio should go to 192.168.200.10:10860 (which is also the Asterisk box)
# U 2008/02/13 13:58:24.691638 192.168.200.10:5060 -> 192.168.200.30:5060 INVITE sip:9613789999@192.168.200.30 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30. Contact: sip:3797271700@192.168.200.10. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 70. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 475. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 192.168.200.10. t=0 0. m=audio 10860 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.
2. SER send an INVITE message on to the PSTN switch. It has correctly put its own address as where the audio should be sent later on. c=IN IP4 10.9.193.148:35010
# U 2008/02/13 13:58:24.697275 10.9.193.135:5060 -> 10.9.193.130:5060 INVITE sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30. Contact: sip:3797271700@192.168.200.10:5060. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. User-Agent: Asterisk PBX. Max-Forwards: 16. Date: Wed, 13 Feb 2008 14:00:08 GMT. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Content-Type: application/sdp. Content-Length: 491. . v=0. o=root 23759 23759 IN IP4 192.168.200.10. s=session. c=IN IP4 10.9.193.148. 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. a=nortpproxy:yes.
3. The PSTN switch send back a TRYING message.
# U 2008/02/13 13:58:24.701458 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 100 Trying. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Contact: sip:9613789999@10.9.193.130. Content-Length: 0. .
4. SER server sends the TRYING message on to Asterisk.
# U 2008/02/13 13:58:24.696951 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. Server: Sip EXpress router (0.9.6 (i386/freebsd)). Content-Length: 0. .
5. PSTN switch sends the SER box a RINGING message.
# U 2008/02/13 13:58:24.799647 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Contact: sip:9613789999@10.9.193.130. Content-Length: 0. .
6. SER box sends on the RINGING message to the Asterisk box.
# U 2008/02/13 13:58:24.802106 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 180 Ringing. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Contact: sip:9613789999@10.9.193.130:5060. Content-Length: 0. .
7. PSTN switch indicates the called party has answered to SER and gives its bearer/audio address & port (10.9.193.146:28006).
# U 2008/02/13 13:58:32.736665 10.9.193.130:5060 -> 10.9.193.135:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 10.9.193.135;branch=z9hG4bK606.deb16814.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Contact: sip:9613789999@10.9.193.130. Content-Type: application/sdp. Content-Length: 175. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.146 t=0 0 m=audio 28006 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - -
8. SER sends Asterisk the OK with the edited-but-WRONG bearer IP address 10.9.193.148:35012, INSTEAD of the reachable 192.168.200.30:35012 value that should have been sent.
# U 2008/02/13 13:58:32.743185 192.168.200.30:5060 -> 192.168.200.10:5060 SIP/2.0 200 OK. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 INVITE. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK3ef39ef4;rport=5060. Server: DC-SIP/1.2. Supported: timer. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Contact: sip:9613789999@10.9.193.130:5060. Content-Type: application/sdp. Content-Length: 193. . v=0 o=- 3411921616 3411921696 IN IP4 10.9.193.130 s=- c=IN IP4 10.9.193.148 t=0 0 m=audio 35012 RTP/AVP 0 a=sendrecv a=ptime:20 a=rtpmap:0 PCMU/8000 a=silenceSupp:off - - - - a=nortpproxy:yes.
And DING, we are in trouble, because the 10.9.193.148 is the wrong IP address on the SER/rtpproxy box that the Asterisk server should send the audio to, a network that the Asterisk server can't reach.
SER/rtpproxy should have edited that to read c=IN IP4 192.168.200.30 the interface facing towards the SIP phone, one of the two interfaces specified in the SER config file and rtpproxy invocation, AND started listening there.
So, no audio from Asterisk will ever reach the SER/rtpproxy box, and rtpproxy will just sit there and wait.
Note also that rtpproxy only listens on one of the interfaces specified:
lsof -p 852 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME rtpproxy 852 root cwd VDIR 0,90 512 2 / rtpproxy 852 root rtd VDIR 0,90 512 2 / rtpproxy 852 root txt VREG 0,93 71102 386745 /usr/local/bin/rtpproxy rtpproxy 852 root txt VREG 0,90 158712 94213 /libexec/ld-elf.so.1 rtpproxy 852 root txt VREG 0,90 922668 235591 /lib/libc.so.6 rtpproxy 852 root 0u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 1u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 2u VCHR 0,6 0t0 6 /dev/null rtpproxy 852 root 3u unix 0xc2e4d164 0t0 /var/run/rtpproxy.sock rtpproxy 852 root 7u IPv4 0xc200f870 0t0 UDP 10.9.193.148:35010 rtpproxy 852 root 8u IPv4 0xc200fb40 0t0 UDP 10.9.193.148:35011 rtpproxy 852 root 9u IPv4 0xc200f0b4 0t0 UDP 10.9.193.148:35012 rtpproxy 852 root 10u IPv4 0xc200fd5c 0t0 UDP 10.9.193.148:35013
Swapping the order that the IP addresses are listed on the rtpproxy command line appears to dictate which address will be used exclusively, rather than using whichever is appropriate for the network of the destination.
Why rtpproxy opens four sockets per call is another question for later.
Now audio is seen flowing from the PSTN switch to the SER box, which seems correct:
U 2008/02/13 13:58:32.692840 10.9.193.146:28006 -> 10.9.193.148:35010 ........ 9............................................................................... ................................................................................ ...
But we see no audio from the Asterisk server reaching the SER/rtpproxy server, because the SIP phone was given the wrong address by SER/rtpproxy. It is probably sending audio out, but it won't reach the SER box.
9. Asterisk Server ACKs the message with the faulty data back to the SER server.
# U 2008/02/13 13:58:32.744216 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport. Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on,sip:10.9.193.135;r2=on; ftag=as0458f259;lr=on. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Contact: sip:3797271700@192.168.200.10. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 70. Content-Length: 0. .
10. SER passes on the ACK message to the PSTN switch.
# U 2008/02/13 13:58:32.745038 10.9.193.135:5060 -> 10.9.193.130:5060 ACK sip:9613789999@10.9.193.130:5060 SIP/2.0. Record-Route: sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on. Record-Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Via: SIP/2.0/UDP 10.9.193.135;branch=0. Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK79c58e2e;rport=5060. From: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. To: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. Contact: sip:3797271700@192.168.200.10. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 102 ACK. User-Agent: Asterisk PBX. Max-Forwards: 16. Content-Length: 0. .
11. PSTN switch tells SER that the called party has hung up.
# U 2008/02/13 14:00:17.113865 10.9.193.130:5060 -> 10.9.193.135:5060 BYE sip:10.9.193.135;r2=on;ftag=as0458f259;lr=on SIP/2.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. From: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. CSeq: 1 BYE. Route: sip:192.168.200.30;r2=on;ftag=as0458f259;lr=on. Route: sip:3797271700@192.168.200.10. Supported: timer. Content-Length: 0. Max-Forwards: 70. .
12. SER passes on the hang-up message to Asterisk.
# U 2008/02/13 14:00:17.116100 192.168.200.30:5060 -> 192.168.200.10:5060 BYE sip:3797271700@192.168.200.10 SIP/2.0. Record-Route: sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on. Record-Route: sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0. Via: SIP/2.0/UDP 10.9.193.130. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. From: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. CSeq: 1 BYE. Supported: timer. Content-Length: 0. Max-Forwards: 16. .
13. Asterisk ACKs the message to SER.
# U 2008/02/13 14:00:17.116898 192.168.200.10:5060 -> 192.168.200.30:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bKd67e.7d582993.0;received=192.168.2 00.30. Via: SIP/2.0/UDP 10.9.193.130. Record-Route: sip:192.168.200.30;r2=on;ftag=17b0000-0-1077770870;lr=on. Record-Route: sip:10.9.193.135;r2=on;ftag=17b0000-0-1077770870;lr=on. From: sip:9613789999@192.168.200.30;tag=17b0000-0-1077770870. To: "VOIP TEST 1000" sip:3797271700@192.168.200.30;tag=as0458f259. Call-ID: 5d27b24903963a384c98f4701f0ce456@192.168.200.30. CSeq: 1 BYE. User-Agent: Asterisk PBX. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. Supported: replaces. Contact: sip:3797271700@192.168.200.10. Content-Length: 0. .
----------------------------------------------------------------------------
Invovation and Configuration
Ser is started with "serctl start" and rtpproxy with rtpproxy -l 10.9.193.148/192.168.200.20
Ser is 0.9.6 and rtpproxy is a 1.1 snapshot from December (the 1.0 RELEASE link on the web site is broken)
Here is the ser.cfg file.
# ----------------------------------------------------------------- # ser.cfg # -----------------------------------------------------------------
# 92.168.200.30 is an interface towards external SIP gear, asterisk # ervers, etc.
listen=192.168.200.30 # INSERT YOUR IP ADDRESS HERE # 0.9.193.135 is an interface directly connected to a PSTN switch # also performing SIP->TDM conversion
listen=10.9.193.135 # INSERT YOUR IP ADDRESS HERE
# mhomed required or ser will not attempt to match destination IPs # with the interface and network that can reach the destination.
mhomed=yes
# ----------------------------------------------------------------- # handbook defaults # -----------------------------------------------------------------
debug=3 fork=yes log_stderror=no sip_warning=no port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://ser:heslo@localhost/ser"
# ----------------------------------------------------------------- # Modules # -----------------------------------------------------------------
loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/textops.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so"
# ----------------------------------------------------------------- # Module settings # -----------------------------------------------------------------
modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://ser:heslo@local host/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password")
modparam("nathelper", "natping_interval", 30) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")
modparam("usrloc", "db_mode", 2)
modparam("registrar", "nat_flag", 6)
modparam("rr", "enable_full_lr", 1)
modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout")
modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted")
# ----------------------------------------------------------------- # Main Route Evaluation # -----------------------------------------------------------------
route { log(1, "ENTERING MAIN ROUTE\n");
if (method=="REGISTER") log(1, "REGISTER message received\n");
if (method=="INVITE") log(1, "INVITE message received\n");
if (method=="ACK") log(1, "ACK message received\n");
if (method=="BYE") log(1, "BYE message received\n");
if (method=="CANCEL") log(1, "CANCEL message received\n");
if (method=="SUBSCRIBE") log(1, "SUBSCRIBE message received\n");
if (method=="NOTIFY") log(1, "NOTIFY message received\n");
if (method=="OPTIONS") log(1, "OPTIONS message received\n");
if (method=="INFO") log(1, "INFO message received\n");
if (method=="MESSAGE") log(1, "MESSAGE message received\n");
if (method=="REFER") log(1, "REFER message received\n");
# ----------------------------------------------------------------- # Sanity Check Section # -----------------------------------------------------------------
log(1, "Performing Sanity Check\n"); if (!mf_process_maxfwd_header("10")) { sl_send_reply("483", "Too Many Hops"); break; };
if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; };
# ----------------------------------------------------------------- # Record Route Section # -----------------------------------------------------------------
log(1, "Entering Record Route\n"); if (method!="REGISTER") { record_route(); };
if (method=="BYE" || method=="CANCEL") { unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Call Tear Down Section # -----------------------------------------------------------------
log(1, "Entering Tear Down Section\n"); if (method=="BYE" || method=="CANCEL") { log(1, "Method was Equal to BYE or Cancel\n"); unforce_rtp_proxy(); }
# ----------------------------------------------------------------- # Loose Route Section # -----------------------------------------------------------------
log(1, "Entering Loose Route Section\n");
if (loose_route()) { log(1, "Call is Loose_Route\n"); if ((method=="INVITE" || method=="REFER") && !has_totag()) { sl_send_reply("403", "Forbidden"); break; };
if (method=="INVITE") { log(1, "Loose Route Method equals Invite\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials\n"); consume_credentials();
if (nat_uac_test("19")) { log(1, "Client was client nat test 19\n"); setflag(6); force_rport(); fix_nated_contact(); }; force_rtp_proxy("l"); }; route(1); break; };
# ----------------------------------------------------------------- # Call Type Processing Section # -----------------------------------------------------------------
log(1, "Entering Call Type Processing\n"); if (!is_uri_host_local()) { if (is_from_local() || allow_trusted()) { log(1, "URI is local or Trusted\n"); log(1, "Going to route 4\n");
route(4); log(1, "Going to route 1\n"); route(1); } else { sl_send_reply("403", "Forbidden"); }; break; };
if (method=="ACK") { log(1, "Call Processing ACK\n"); route(1); break; } else if (method=="CANCEL") { log(1, "Call Processing CANCEL\n"); route(1); break; } else if (method=="INVITE") { log(1, "Call Processing INVITE\n"); route(3); break; } else if (method=="REGISTER") { log(1, "Call Processing REGISTER\n"); route(2); break; };
lookup("aliases"); log(1, "Lookup Aliases\n"); if (!is_uri_host_local()) { log(1, "Call Processing uri_host_local\n"); log(1, "Going to route 4\n"); route(4); log(1, "Going to route 1\n"); route(1); break; };
if (!lookup("location")) { log(1, "Call Processing lookup location\n"); sl_send_reply("404", "User Not Found"); break; };
route(1); }
# ----------------------------------------------------------------- # Default Message Handler # -----------------------------------------------------------------
route[1] { log(1, "Entering ROUTE[1]\n");
t_on_reply("1");
setflag(1);
if (!t_relay()) { if (method=="INVITE" && isflagset(6)) { log(1, "unforce rtp proxy\n"); unforce_rtp_proxy(); }; sl_reply_error(); }; }
# ----------------------------------------------------------------- # REGISTER Message Handler # -----------------------------------------------------------------
route[2] { log(1, "Entering ROUTE[2]\n"); sl_send_reply("100", "Trying");
if (!search("^Contact:[ ]**") && nat_uac_test("19")) { log(1, "searching contact\n"); setflag(6); fix_nated_register(); force_rport(); };
if (!www_authorize("","subscriber")) { log(1, "authorize challenge\n"); www_challenge("","0"); break; };
if (!check_to()) { sl_send_reply("401", "Unauthorized"); log(1, "401 unauth break\n"); break; };
consume_credentials();
if (!save("location")) { sl_reply_error(); }; }
# ----------------------------------------------------------------- # INVITE Message Handler # -----------------------------------------------------------------
route[3] { log(1, "Entering ROUTE[3]\n");
if (!allow_trusted()) { log(1, "Allow Trusted True\n"); if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; log(1, "Consume Credentials route 3\n"); consume_credentials(); };
if (uri=~"^sip:1[0-9]{10}@") { strip(1); };
if (nat_uac_test("19")) { setflag(6); }
lookup("aliases"); if (!is_uri_host_local()) { route(4); route(1); break; };
if (uri=~"^sip:011[0-9]*@") { # International PSTN route(4); route(5); break; };
if (!lookup("location")) { log(1, "Domestic PSTN\n"); if (uri=~"^sip:[0-9]{10}@") { # Domestic PSTN route(4); route(5); break; };
sl_send_reply("404", "User Not Found"); break; };
route(4); route(1); }
# ----------------------------------------------------------------- # NAT Traversal Section # -----------------------------------------------------------------
route[4] { log(1, "Entering ROUTE[4]\n");
if (isflagset(6)) { log(1, "Running NAT Traversal\n"); force_rport(); fix_nated_contact(); force_rtp_proxy(); } }
# ----------------------------------------------------------------- # PSTN Handler # -----------------------------------------------------------------
route[5] { log(1, "Entering ROUTE[5]\n"); rewritehost("10.9.193.130:5060"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); log(1, "Rewrote IP for PSTN Gateway\n"); log(1, "Returning to Route 1\n"); route(1); }
# ----------------------------------------------------------------- # Return Message To Sender # -----------------------------------------------------------------
onreply_route[1] { log(1, "Reached Onreply Route\n");
if (isflagset(6) && status=~"(180)|(183)|2[0-9][0-9]") { if (!search("^Content-Length:[ ]*0")) { log(1, "Running Force RTP Proxy\n"); force_rtp_proxy(); }; };
if (nat_uac_test("1")) { log(1, "Fix Nated Contact\n"); fix_nated_contact(); }; }
# ----------------------------------------------------------------- # End of ser.cfg # -----------------------------------------------------------------
Whew, so with all that information, the question comes down to:
How do you convince rtpproxy to listen on and tell SER about the right IP addresses when there are two interfaces and you have told rtpproxy about both of them?
Thanks in advance for assistance on this!
Frank
-
Frank Durda IV