25 Jan
2017
25 Jan
'17
5:16 p.m.
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@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(a)carrier.peering.telecom.im
From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <sip:4.4.4.4:5060>
Route:
<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@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(a)carrier.peering.telecom.im
From: "+44792498881474"
<sip:+441444680332@es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <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
25 Jan
25 Jan
5:28 p.m.
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@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(a)carrier.peering.telecom.im
*From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2*
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <sip:4.4.4.4:5060>
Route:
<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@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(a)carrier.peering.telecom.im
*From: "+44792498881474"
<sip:+441444680332@es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2*
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
6:37 p.m.
Hi Daniel,
This is the initial invite from the carrier;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
________________________________
From: sr-users <sr-users-bounces(a)lists.sip-router.org> on behalf of
Daniel-Constantin Mierla <miconda(a)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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone><sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+441444680332@es132y$}-9><sip:+441444680332@es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@lists.sip-router.org<mailto:sr-users@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>
6:42 p.m.
Sorry Daniel, hit reply by mistake!
So
The initial invite shows;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
And the ACK has the resolved From domain, as in IP address and port;
From: "+44792498881474"
<sip:+44792498881474@192.168.226.51:5080;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
Although that is the case on other calls that work.
Shall I setup some debug on a lab instance and capture?
Thanks
Jon
________________________________
From: Jonathan Hunter <hunterj91(a)hotmail.com>
Sent: 25 January 2017 15:37
To: Kamailio (SER) - Users Mailing List; miconda(a)gmail.com
Subject: Re: [SR-Users] Issue with From address being modified in ACK when UAC module used
version 4.1
Hi Daniel,
This is the initial invite from the carrier;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
________________________________
From: sr-users <sr-users-bounces(a)lists.sip-router.org> on behalf of
Daniel-Constantin Mierla <miconda(a)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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone><sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+441444680332@es132y$}-9><sip:+441444680332@es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@lists.sip-router.org<mailto:sr-users@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>
7:14 p.m.
The mechanism to update and restore the From header is relying on the
fact that the UA sticks to the RFC requirements of not changing the
values, because it using a XOR masking algorithm.
If the From is not preserved by the UA, then it screws up the
update/restore for subsequent requests/replies. The newer versions have
a safety check so in such case it doesn't perform the change.
The alternatives to cope with this situations are:
1) don't do auto restore -- this can be controlled by uac module
parameter -- if the UA changes the From, then it doesn't expect to be
the same always. I use it quite often these day, because all the UAs I
have seen lately they match the dialog with From and To tags (as per
RFC3261). No need to use From URI/To URI as was required by RFC2543 (and
RFC3261 has a constraint of backward compatibility).
What I do in this cases is to replace From/To only for initial requests
to what I need. For all the requests within dialog I replace them with
annonymous(a)domain.com
2) rely on dialog module to keep the old and new values for From/To
(instead of default one which uses the record-route parameter) -- it
looks like being available on 4.1.x:
https://www.kamailio.org/docs/modules/4.1.x/modules/uac.html#uac.p.restore_…
Cheers,
Daniel
On 25/01/2017 16:42, Jonathan Hunter wrote:
Sorry Daniel, hit reply by mistake!
So
The initial invite shows;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
And the ACK has the resolved From domain, as in IP address and port;
From: "+44792498881474"
<sip:+44792498881474@192.168.226.51:5080;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
Although that is the case on other calls that work.
Shall I setup some debug on a lab instance and capture?
Thanks
Jon
------------------------------------------------------------------------
*From:* Jonathan Hunter <hunterj91(a)hotmail.com>
*Sent:* 25 January 2017 15:37
*To:* Kamailio (SER) - Users Mailing List; miconda(a)gmail.com
*Subject:* Re: [SR-Users] Issue with From address being modified in
ACK when UAC module used version 4.1
Hi Daniel,
This is the initial invite from the carrier;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
------------------------------------------------------------------------
*From:* sr-users <sr-users-bounces(a)lists.sip-router.org> on behalf of
Daniel-Constantin Mierla <miconda(a)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:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
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@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(a)carrier.peering.telecom.im
*From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2*
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <sip:4.4.4.4:5060>
Route:
<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@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(a)carrier.peering.telecom.im
*From: "+44792498881474"
<sip:+441444680332@es132y$}-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2*
To: "+441624111111"
<sip:+441624111111@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF
CSeq: 1 ACK
Contact: <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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
7:36 p.m.
Hi Daniel,
Ok perfect thank you for the detailed response, I will look to test and implement!
Thank you!
Jon
________________________________
From: Daniel-Constantin Mierla <miconda(a)gmail.com>
Sent: 25 January 2017 16:14
To: Jonathan Hunter; Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] Issue with From address being modified in ACK when UAC module used
version 4.1
The mechanism to update and restore the From header is relying on the fact that the UA
sticks to the RFC requirements of not changing the values, because it using a XOR masking
algorithm.
If the From is not preserved by the UA, then it screws up the update/restore for
subsequent requests/replies. The newer versions have a safety check so in such case it
doesn't perform the change.
The alternatives to cope with this situations are:
1) don't do auto restore -- this can be controlled by uac module parameter -- if the
UA changes the From, then it doesn't expect to be the same always. I use it quite
often these day, because all the UAs I have seen lately they match the dialog with From
and To tags (as per RFC3261). No need to use >From URI/To URI as was required by
RFC2543 (and RFC3261 has a constraint of backward compatibility).
What I do in this cases is to replace From/To only for initial requests to what I need.
For all the requests within dialog I replace them with
annonymous@domain.com<mailto:annonymous@domain.com>
2) rely on dialog module to keep the old and new values for From/To (instead of default
one which uses the record-route parameter) -- it looks like being available on 4.1.x:
https://www.kamailio.org/docs/modules/4.1.x/modules/uac.html#uac.p.restore_…
Cheers,
Daniel
On 25/01/2017 16:42, Jonathan Hunter wrote:
Sorry Daniel, hit reply by mistake!
So
The initial invite shows;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone><sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
And the ACK has the resolved From domain, as in IP address and port;
From: "+44792498881474"
<sip:+44792498881474@192.168.226.51:5080;user=phone><sip:+44792498881474@192.168.226.51:5080;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
Although that is the case on other calls that work.
Shall I setup some debug on a lab instance and capture?
Thanks
Jon
________________________________
From: Jonathan Hunter <hunterj91@hotmail.com><mailto:hunterj91@hotmail.com>
Sent: 25 January 2017 15:37
To: Kamailio (SER) - Users Mailing List;
miconda@gmail.com<mailto:miconda@gmail.com>
Subject: Re: [SR-Users] Issue with From address being modified in ACK when UAC module used
version 4.1
Hi Daniel,
This is the initial invite from the carrier;
From: "+44792498881474"
<sip:+44792498881474@carrier.peering.telecom.im;user=phone><sip:+44792498881474@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5
________________________________
From: sr-users
<sr-users-bounces@lists.sip-router.org><mailto:sr-users-bounces@lists.sip-router.org>
on behalf of Daniel-Constantin Mierla
<miconda@gmail.com><mailto:miconda@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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+44792498881474@192.168.24.8:5080;user=phone><sip:+44792498881474@192.168.24.8:5080;user=phone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@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@carrier.peering.telecom.im<mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im>
From: "+44792498881474"
<sip:+441444680332@es132y$}-9><sip:+441444680332@es132y$%7D-9>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2
To: "+441624111111"
<sip:+441624111111@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@lists.sip-router.org<mailto:sr-users@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>
--
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>
2861
days inactive
2861
days old
5 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Jonathan Hunter