12 Mar
2009
12 Mar
'09
6:07 p.m.
I have recently noticed that despite having a
$record_route_nated = true;
in the route[PSTN_FORWARD] of ser.cfg, the INVITES and
such sent on do not have a Record-Route header.
In our NATed situation, probably the only thing this
would cause problems with would be when the called party
hangs up first, SER and the calling party never find out
about it, since the calling party IP is not reachable
from the PSTN switch NATed address space, so the single
BYE message sent by the PSTN switch probably whizzes
by to an unreachable destination address. So the calling
party remains off-hook and just gets dead air. When
the calling party finally disconnects, the SER passes
the caller-initiated BYE to the PSTN switch which
returns a 481 because it thinks the call was over ages
earlier. Or at least this is what appears to be happening.
Here is the PSTN_FORWARD in use, not that different
from the PSTN gateway example ser.cfg:
route[PSTN_FORWARD]
{
# Set where packets should be sent. If you don't do this here,
# OPTIONS and other messages will be transmitted back to the
# outside interface and processed all over again, and you eventually
# get a Too Many Hops error on every OPTIONS message.
# Code to make this point in multiple directions would be needed
# to implement two-way origination.
rewritehost("10.x.x.x"); #Send to SIP-TDM switch
if (method == "BYE" || method == "CANCEL") {
unforce_rtp_proxy();
}
else if (method == "INVITE") {
# Force record routing if either party is behind NAT
$record_route_nated = true;
# log(1, "NAT Mangle Force RTP Proxy\n");
force_rtp_proxy("e");
}
t_on_reply("PSTN_REPLY");
# if this is called from the failure route we need to open a new
branch
if (isflagset(FLAG_FAILUREROUTE)) {
append_branch();
}
# if this is an initial INVITE (without a To-tag) we might try another
# (forwarding or voicemail) target after receiving an error
if (method=="INVITE" && @to.tag=="") {
t_on_failure("FAILURE_ROUTE");
}
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
}
drop;
}
The resulting INVITE that is being sent on to the PSTN switch
looks like:
INVITE sip:+1xxxxxxxxxx@10.x.x.x:5060;npdi=yes SIP/2.0
Via: SIP/2.0/UDP 10.x.x.x;branch=z9hG4bK6804.1cb4cb23.0
Via: SIP/2.0/UDP 10.x.x.x:5060;branch=z9hG4bK1kpu0b20e0fgogk9c6d0.1
f:
<sip:+1xxxxxxxxxx;jip=xxxxxx@10.x.x.x:5060;user=phone>;tag=d0a-13c4-83e003-64bd22fa-83e003
t: <sip:+1xxxxxxxxxx@10.x.x.x:5060;user=phone>
i: a249e890d8184d0a13c483e0033230d1ff3b57654c1d4018-0143-8166
CSeq: 1 INVITE
User-agent: CS2000_NGSS/9.0
P-Asserted-Identity: <sip:+1xxxxxxxxxx;jip=xxxxxx@10.x.x.x;user=phone>
Max-Forwards: 16
k: 100rel
Allow: ACK,BYE,CANCEL,INVITE,OPTIONS,INFO,SUBSCRIBE,REFER,NOTIFY,PRACK
m: <sip:10.x.x.x:5060;transport=udp>
c: application/SDP
l: 231
v=0
o=- 15109843 15109843 IN IP4 10.x.x.x
s=-
c=IN IP4 10.x.x.x
t=0 0
m=audio 44464 RTP/AVP 0 101
b=AS:80
a=ptime:20
a=rtpmap:0 PCMU/8000/1
a=rtpmap:101 telephone-event/8000/1
a=fmtp:101 0-15
a=nortpproxy:yes
So, any ideas as to why the "$record_route_nated = true"
doesn't seem to be having any effect, eg no Record-Route
shows up in outbound messages? I know SER is passing
through the above code because I can uncomment the
"NAT Mangle" comment and see it in the logs.
Is there perhaps some module that must be present that
we may have eliminated that makes Record-Route get
emitted?
Thanks again!