Hi Henning,

My inbound carrier has done some digging and discovered that the reason is they choose the *first* address from the *last* Record-Route header.

Most gateways apparently add multiple Record-Route headers, whereas when we get a OK to our INVITE from the carrier, the various Record-Route headers have been compiled into a single Record-Route header like:

Record-Route: <sip:85.13.242.57;lr=on>
Record-Route: <sip:85.13.242.55;lr=on>
--> INVITE
Record-Route: <sip:8.13.22.57;lr=on>
Record-Route: <sip:8.13.22.55;lr=on>

<-- OK
Record-Route: <sip:53.116.5.147;lr=on>,<sip:8.13.22.57;lr=on>,<sip:8.13.22.55;lr=on>

Is this normal behaviour of SIP, and either way is there any way to ask Kamailio to mangle the 200 OK to split the Record-Route header into the separate entries that is possibly more "standard"…?

Cheers,
Leo

On 6 May 2013, at 12:20, Henning Westerholt <hw@kamailio.org> wrote:

Am Freitag, 3. Mai 2013, 16:54:29 schrieb Leo Brown:
I added record_route() and now I see an extra record-route and Via: header:

.9........INVITE sip:44800800150@pstn-out.netfuse.net SIP/2.0
Record-Route: <sip:85.13.242.55;lr=on>
Via: SIP/2.0/UDP 85.13.242.55;branch=z9hG4bK388f.04bc8632.1
Via: SIP/2.0/UDP 81.88.163.210:5060;rport=5060;branch=z9hG4bK82ae6ced
   INVITE sip:44800800150@our-pstn-switch SIP/2.0
   Record-Route: <sip:mvno-edge;lr=on>
   Via: SIP/2.0/UDP mvno-edge;branch=z9hG4bK388f.04bc8632.1
   Via: SIP/2.0/UDP mvno-carrier:5060;rport=5060;branch=z9hG4bK82ae6ced
   Contact: <sip:441234567890@mvno-carrier:5060>

I have replaced the relevant IP addresses in the example with mvno-edge,
mvno-carrier, and outbound-carrier. So the route got "recorded" but the
Contact: still referenced my mvno-carrier when inviting my
outbound-carrier.

Accordingly, I do not get the BYE message from my originating mvno-carrier,
after I send them 200 OK they try to talk to my outbound-carrier.

Note this is how I am routing the call to my gateway:

       # Change destination URI to our carrier
       $ru = "sip:" + $rU + "@" +
$sel(cfg_get.gateways.outbound_carrier_1);

Any other ideas on how the Contact header should be modified?

Hi Leo,

maybe the originating gateway user agent is not configured correctly. Normally
one does not need to modify the Contact header for this functionality.

The originating user agent needs to "learn" the route set that he should
follow and specify then this the respective Route headers.

Take a look to this example on how it works in detail:

http://www.in2eps.com/fo-sip/tk-fo-sip-dialog.html

BTW, if your proxy on the path also needs to honour Route sets you need to use
also the loose_route function in rr module.

Henning Westerholt