[SR-Users] Issue with From address being modified in ACK when UAC module used version 4.1

Jonathan Hunter hunterj91 at hotmail.com
Wed Jan 25 16:37:27 CET 2017


Hi Daniel,


This is the initial invite from the carrier;


From: "+44792498881474" <sip:+44792498881474 at carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5




________________________________
From: sr-users <sr-users-bounces at lists.sip-router.org> on behalf of Daniel-Constantin Mierla <miconda at gmail.com>
Sent: 25 January 2017 14:28
To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Issue with From address being modified in ACK whishen UAC module used version 4.1


Hello,


is the From in incoming INVITE same as in ACK?


Cheers,
Daniel

On 25/01/2017 15:16, Jonathan Hunter wrote:
Hi Guys,

running kamailio 4.1.4 and using uac_replace_from, I am seeing a strange issue with the proxying of an ACK message back from a carrier to freeswitch on the ingress path into a network.

So its just a normal call inbound, where on outbound leg we modify the From address, on the inbound leg all remains the same.

Now after the ingress side receives the 200ok, it sends an ACK as below;

ACK sip:+441624111111 at 192.168.24.8:5080;transport=udp SIP/2.0
Via: SIP/2.0/UDP 4.4.4.4:5060;branch=z9hG4bK+7f5c8c756ae3b26a956b33b88c77c29f1+sip+3+aa6d1466
Call-ID: 8791dbd3855eeafd484f397de6e2f76e at carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e at carrier.peering.telecom.im>
From: "+44792498881474" <sip:+44792498881474 at 192.168.24.8:5080;user=phone><sip:+44792498881474 at 192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111" <sip:+441624111111 at 8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <sip:4.4.4.4:5060><sip:4.4.4.4:5060>
Route: <sip:192.168.24.8;lr=on;ftag=carrier.peering.telecom.im+3+863d20a3+1b9801d2;vsf=AAAAAAAAAAYNBgAPAAgLAgZ3UTMACgBXFUsVFwwcDkAKTwMZGh0YAA8KDkEEQ1NYC0NDXgdOFRpSHg1vbmU-><sip:192.168.24.8;lr=on;ftag=carrier.peering.telecom.im+3+863d20a3+1b9801d2;vsf=AAAAAAAAAAYNBgAPAAgLAgZ3UTMACgBXFUsVFwwcDkAKTwMZGh0YAA8KDkEEQ1NYC0NDXgdOFRpSHg1vbmU->
Content-Length: 0
Max-Forwards: 68

However kamailio changes the From address;


ACK sip:+441624111111 at 192.168.24.8:5080;transport=udp SIP/2.0
Via: SIP/2.0/UDP 109.73.69.165:5060;branch=z9hG4bKc1ce.47974fc3da2b669a78f2dcc9a057a127.0
Via: SIP/2.0/UDP 4.4.4.4:5060;rport=5060;branch=z9hG4bK+7f5c8c756ae3b26a956b33b88c77c29f1+sip+3+aa6d1466
Call-ID: 8791dbd3855eeafd484f397de6e2f76e at carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e at carrier.peering.telecom.im>
From: "+44792498881474" <sip:+441444680332 at es132y$}-9><sip:+441444680332 at es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111" <sip:+441624111111 at 8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <sip:4.4.4.4:5060><sip:4.4.4.4:5060>
Content-Length: 0
Max-Forwards: 67

Causing FreeSWITCH to not recognise the request, and therefore not send an ACK.

There are no rules set against the ACK processing.

Has anyone seen this before? We dont know when it  started happening which doesnt help, I will look to setup debug on test environment but just wondered if this is an issue thats been seen before?

Many thanks in advance.

Jon




_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users at lists.sip-router.org<mailto:sr-users at lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
Daniel-Constantin Mierla
www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com<http://www.asipto.com>
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com<http://www.kamailioworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20170125/700236be/attachment.html>


More information about the sr-users mailing list