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!