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@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30. Contact: sip:3797271700@192.168.200.10. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@192.168.200.30 out_uri=sip: 9613789999@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@192.168.200.30 out_uri=sip: 9613789999@10.9.193.130 via_cnt==0". . # U 192.168.200.10:5060 -> 192.168.200.30:5060 ACK sip:9613789999@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559. Contact: sip:3797271700@192.168.200.10. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30;tag=4ba1e3c69d2fb2c7ac6c1995ba01e0a8-e559. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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@192.168.200.30 out_uri=sip: 9613789999@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@10.9.193.130 SIP/2.0. Record-Route: sip:9613789999@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@192.168.200.30;tag=as0e33db9b. To: sip:9613789999@192.168.200.30. Contact: sip:3797271700@192.168.200.10:5060. Call-ID: 45b82ab572cfaddd18afc02a5cd4275c@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