[Serusers] Is SER doc PSTN Gateway example incomplete/incompatible with Asterisk?

Thu Feb 7 00:03:36 CET 2008

Stefan Sayer wrote:
> SER will by default send the packet from the socket it received the
> request on. So try using the right IP (10.9.193.135 in that case) at the
> asterisk box, or
> 
> you can also use force_send_socket
> (force_send_socket([proto:]address[:port]) to set the outgoing socket.
> In your setup with one 'public' interface and asterisk sending to the
> other one you will actually need it.

I guess I didn't describe our setup well enough.  Here it is
drawn a different way.  Here is network "A" /24

[SIP phone 192.168.200.20]-----+
[Asterisk box 192.168.200.10]--+----[SER interface re2 192.168.200.30]
(Three devices on this network, plus the switch)

and Network "B" /28

[SER interface re1 10.9.193.135]-----[LCS Switch SIP interface 10.9.193.130]
(two devices on this network, plus a switch)

and Network "C" /29

[SER interface re0 10.9.193.148]-----[LCS Switch Bearer interface 10.9.193.146]
(two devices on this network, plus a router)

These are the basic connections and isolated networks,   Each network
can't see the other (intentional).   Only a device connected to two or
more of the networks can see into those directly connected networks.

So, here is a test call as it comes in from the Asterisk box on re2:

ser1#  ngrep -W byline -d re2 port 5060
interface: re2 (192.168.200.0/255.255.255.0)
filter: (ip or ip6) and ( port 5060 )

#
U 192.168.200.10:5060 -> 192.168.200.30:5060
INVITE sip:9613789999 at 192.168.200.30 SIP/2.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK72e3cd8d;rport.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>.
Contact: <sip:3797271700 at 192.168.200.10>.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Date: Wed, 06 Feb 2008 16:10:40 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 289.
.
v=0.
o=root 1245 1245 IN IP4 192.168.200.10.
s=session.
c=IN IP4 192.168.200.10.
t=0 0.
m=audio 10424 RTP/AVP 0 3 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

#
U 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=z9hG4bK72e3cd8d;rport=5060.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 102 INVITE.
Server: Sip EXpress router (0.9.6 (i386/freebsd)).
Content-Length: 0.
Warning: 392 192.168.200.30:5060 "Noisy feedback tells:  pid=29750 req_src_ip=19
2.168.200.10 req_src_port=5060 in_uri=sip:9613789999 at 192.168.200.30 out_uri=sip:
9613789999 at 10.9.193.130 via_cnt==1".
.

time passes...

#
U 192.168.200.30:5060 -> 192.168.200.10:5060
SIP/2.0 408 Request Timeout.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK72e3cd8d;rport=5060.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 102 INVITE.
Server: Sip EXpress router (0.9.6 (i386/freebsd)).
Content-Length: 0.
Warning: 392 192.168.200.30:5060 "Noisy feedback tells:  pid=29760 req_src_ip=19
2.168.200.10 req_src_port=5060 in_uri=sip:9613789999 at 192.168.200.30 out_uri=sip:
9613789999 at 10.9.193.130 via_cnt==0".
.
#
U 192.168.200.10:5060 -> 192.168.200.30:5060
ACK sip:9613789999 at 192.168.200.30 SIP/2.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK72e3cd8d;rport.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559.
Contact: <sip:3797271700 at 192.168.200.10>.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 102 ACK.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Content-Length: 0.
.

#
U 192.168.200.10:5060 -> 192.168.200.30:5060
BYE sip:9613789999 at 192.168.200.30 SIP/2.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK1f3f55f0;rport.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 103 BYE.
User-Agent: Asterisk PBX.
Max-Forwards: 70.
Content-Length: 0.
.

#
U 192.168.200.30:5060 -> 192.168.200.10:5060
SIP/2.0 404 User Not Found.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK1f3f55f0;rport=5060.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 103 BYE.
Server: Sip EXpress router (0.9.6 (i386/freebsd)).
Content-Length: 0.
Warning: 392 192.168.200.30:5060 "Noisy feedback tells:  pid=29748 req_src_ip=19
2.168.200.10 req_src_port=5060 in_uri=sip:9613789999 at 192.168.200.30 out_uri=sip:
9613789999 at 192.168.200.30 via_cnt==1".
.

So just about everything looks sane here apart from these three things:

1.  Call failed to go anywhere (more on that in a moment)

2.  This 404 User Not Found reply to the BYE.  What's this?

3.  The "Noisy feedback tells" warning.  Bad or just annoying?

Meanwhile, during all of that activity on interface re2
(between Asterisk and SER system), we see this on interface
re1 (between SER and PSTN gateway):

ser1# ngrep -W byline -d re1 port 5060
interface: re1 (10.9.193.128/255.255.255.240)    NOTE CORRECT NETBLOCK & SIZE)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.200.30:5060 -> 10.9.193.130:5060       NOTE INCORRECT SENDER FOR THIS NETBLOCK
INVITE sip:9613789999 at 10.9.193.130 SIP/2.0.
Record-Route: <sip:9613789999 at 192.168.200.30:5060;nat=yes;ftag=as0e33db9b;lr=on>.
Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bK836b.f113c606.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK72e3cd8d;rport=5060.
From: "VOIP TEST 1000" <sip:3797271700 at 192.168.200.30>;tag=as0e33db9b.
To: <sip:9613789999 at 192.168.200.30>.
Contact: <sip:3797271700 at 192.168.200.10:5060>.
Call-ID: 45b82ab572cfaddd18afc02a5cd4275c at 192.168.200.30.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 16.
Date: Wed, 06 Feb 2008 16:10:40 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 289.
.
v=0.
o=root 1245 1245 IN IP4 192.168.200.10.
s=session.
c=IN IP4 192.168.200.10.
t=0 0.
m=audio 10424 RTP/AVP 0 3 8 101.
a=rtpmap:0 PCMU/8000.
a=rtpmap:3 GSM/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

repeated a number of times, but no reply is seen because the
return address of the SER system on the packets and in the payload
is that of the re2 interface, not the re1 interface that this
packet was emitted on.   The PSTN gateway device therefore
can't get a reply back to the SER system.   The SER system
should have given 10.9.193.135 as the reply address on this
interface, not 192.168.200.30.   Clearly the OS knows
the correct interface to send the packet out on, but SER may
not be aware that this is happening.

Note that the above test was done with no listen and no alias
entries in the ser.cfg file, and the result appears unchanged
from when values were specified (see previous mails).

So, this is a case of message sent out of the SER on
thr re1 interface towards the PSTN switch, and
not a reply packet in response to the INVITE originally
received on the re2 interface.

It still looks like SER for some reason is forcing the return
address to be the first interface address it comes across
when it starts, rather than using a reply address appropriate
for the interface and network that the packet is leaving the
SER server on.

Now, as to using force_send_socket(), how exactly does this
work?  I have not located any documentation other than "added to code"
comments in the .c files, so its impact is not clear.

For example, does force_send_socket() affect just the next packet
being transmitted, or does it get used for all packets sent from
this point forward, until another force_send_socket() call is made?
If it just applies to one packet, should it force_send_socket()
be invoked in route[5], after the rewritehost()  and avp_write,
but before route(1)?

As we only want to fix the packets headed out the
re1 interface (to the PSTN switch) to have a reachable return
address for that network, and not disturb the packets transmitted
out the re2 interface (back towards the asterisk box), we need
to know how long the effects of a force_send_socket() last.

So if force_send_socket applies to ALL subsequent socket writes,
this means we must save and restore the original values
following its use on packets going out the re1 interface.
I see there is a get_send_socket  that might accomplish
this.  What's the best way to hold on to something
like this for later use in a force_send_socket() call?
Assuming it is a persistent setting, where would be the
appropriate place to save, set and then restore to force the
desired behavior?

This actually feels somewhat klunky, and I suspect that this may
not be the appropriate solution as someone must be using a
SER box with more than network interface and deal with this
very situation.  There are lots of daemons listening on UNIX
servers with multiple interfaces that have to do nothing
special at all to get outgoing packets to contain the
right Sender addresses. including DNS servers that are
making queries that are also using UDP.

In our case, the PSTN switch is a tad dim in the routing department
on the signaling interface, and signaling destinations it talks
to need to be in the same netblock as the signaling
interfaces on that switch.  (The limitations on the bearer
side are even more primitive, with all packets sent to a
specific single MAC address (determined when that interface
first became active) regardless of the actual destination
address on the packet that the switch emits.  Ick.)

I think I have enough hardware in front of the bearer
interfaces on that switch to hide its simple view of the
world, but the SIP signaling side would really like
packets it receives from the SER system to be correctly
addressed.

Thanks for the ideas and any more you have,

Frank