[Serusers] Problem with Record-Route not being added

[Nils Ohlmeier]

> 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.

It seems like you expect that just setting an AVP is enough to make SER
insert a Record-Route header. This simply not the case!!!
You need to call record_route() in your script to insert the desired header.

Best regards
  Nils Ohlmeier

> 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 at 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 at 10.x.x.x:5060;user=phone>;tag=d0a-13c4-83e003-64bd22fa-83e003
> t: <sip:+1xxxxxxxxxx at 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 at 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!
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
>