13 Feb
2008
13 Feb
'08
11:14 p.m.
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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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(a)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