Stefan Sayer wrote:
to me it looks like the INVITE is sent out and
retried. an ngrep would
definitely be more revealing about what happens here (ngrep port 5060 -W
byline -d any).
Okay, I can see the problem here. The INVITE is being sent to
the PSTN switch, but with an unreachable return IP address.
That is, SER isn't using the return IP address for the network
interface that the packet is being sent out on, and so the PSTN switch
has no way to send a reply that will go anywhere useful, assuming
it pays attention to the sender address on the UDP packet itself:
ngrep -W byline -d re1 port 5060
interface: re1 (10.9.193.128/255.255.255.240)
filter: (ip or ip6) and ( port 5060 )
#
U 192.168.200.30:5060 -> 10.9.193.130:5060
INVITE sip:9613789999@10.9.193.130 SIP/2.0.
Record-Route: <sip:9613789999@192.168.200.30:5060;nat=yes;ftag=as0bb39a60;lr=on>.
Via: SIP/2.0/UDP 192.168.200.30;branch=z9hG4bK1f28.759505c2.0.
Via: SIP/2.0/UDP 192.168.200.10:5060;branch=z9hG4bK51253e7b;rport=5060.
From: "VOIP TEST 1000" <sip:3797271700@192.168.200.30>;tag=as0bb39a60.
To: <sip:9613789999@192.168.200.30>.
Contact: <sip:3797271700@192.168.200.10:5060>.
Call-ID: 5fece4d70f005f4b3180713e0227258b(a)192.168.200.30.
CSeq: 102 INVITE.
User-Agent: Asterisk PBX.
Max-Forwards: 16.
Date: Wed, 06 Feb 2008 14:46:28 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 15290 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.
As mentioned earlier, the re1 interface IP address
on the SER box is 10.9.193.135, so this should be the
address presented to the PSTN switch for SIP replies,
not the 192.168.200.30, which is on an unreachable network.
In our setup there will be three interfaces involved,
one dealing with SIP only and one dealing with RTP only
(from the PSTN switch), and one from other places
like the Asterisk box with both SIP and RTP packets.
So SER needs to deal with being visible from multiple
interfaces and replying in reachable ways from all.
Arguably, the references to 192.168.200.30 in the invite itself
are also wrong, as that address is not reachable from the
PSTN switch, only the 10.9.193.135 address would be reachable.
So, what's the best way to get SER to do the right thing?
In our config, SER is obviously forcing this behavior (possibly a
result of missing or excess listen or alias settings?),
because a typical program would not encounter this issue,
as telnet/ping run from the SER box go to the right place
and see replies:
ser1# telnet 10.9.193.130
Trying 10.9.193.130...
Connected to 10.9.193.130.
Escape character is '^]'.
This is LABXTXBR549 SP-B
Username:
...
Frank