<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>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.</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>The alternatives to cope with this situations are:</p>
<p><br>
</p>
<p>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).</p>
<p><br>
</p>
<p>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 <a class="moz-txt-link-abbreviated" href="mailto:annonymous@domain.com">annonymous@domain.com</a></p>
<p><br>
</p>
<p>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:</p>
<p><br>
</p>
<p><a class="moz-txt-link-freetext" href="https://www.kamailio.org/docs/modules/4.1.x/modules/uac.html#uac.p.restore_dlg">https://www.kamailio.org/docs/modules/4.1.x/modules/uac.html#uac.p.restore_dlg</a></p>
<p><br>
</p>
Cheers,<br>
Daniel<br>
<br>
<div class="moz-cite-prefix">On 25/01/2017 16:42, Jonathan Hunter
wrote:<br>
</div>
<blockquote
cite="mid:DB3PR02MB06010BA781268E49FD20462BD740@DB3PR02MB060.eurprd02.prod.outlook.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Arial,Helvetica,sans-serif;"
dir="ltr">
<p>Sorry Daniel, hit reply by mistake!</p>
<p><br>
</p>
<p>So</p>
The initial invite shows;
<div><br>
</div>
<div>
<p style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 16px;">From: "+44792498881474"
<a class="moz-txt-link-rfc2396E" href="sip:+44792498881474@carrier.peering.telecom.im;user=phone"><sip:+44792498881474@carrier.peering.telecom.im;user=phone></a>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5<br>
</p>
<div><br>
</div>
And the ACK has the resolved From domain, as in IP address and
port;<br>
<div><br>
<span>From: "+44792498881474"
<a class="moz-txt-link-rfc2396E" href="sip:+44792498881474@192.168.226.51:5080;user=phone"><sip:+44792498881474@192.168.226.51:5080;user=phone></a>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5</span></div>
<div><br>
</div>
<div>Although that is the case on other calls that work.</div>
<div><br>
</div>
<div>Shall I setup some debug on a lab instance and capture?</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Jon</div>
<div>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000" face="Calibri,
sans-serif"><b>From:</b> Jonathan Hunter
<a class="moz-txt-link-rfc2396E" href="mailto:hunterj91@hotmail.com"><hunterj91@hotmail.com></a><br>
<b>Sent:</b> 25 January 2017 15:37<br>
<b>To:</b> Kamailio (SER) - Users Mailing List;
<a class="moz-txt-link-abbreviated" href="mailto:miconda@gmail.com">miconda@gmail.com</a><br>
<b>Subject:</b> Re: [SR-Users] Issue with From address
being modified in ACK when UAC module used version 4.1</font>
<div> </div>
</div>
<div>
<div id="divtagdefaultwrapper" dir="ltr"
style="font-size:12pt; color:#000000;
font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Daniel,</p>
<p><br>
</p>
<p>This is the initial invite from the carrier;</p>
<p><br>
</p>
<p><span>From: "+44792498881474"
<a class="moz-txt-link-rfc2396E" href="sip:+44792498881474@carrier.peering.telecom.im;user=phone"><sip:+44792498881474@carrier.peering.telecom.im;user=phone></a>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5</span><br>
</p>
<p><span><br>
</span></p>
<p><span><br>
</span></p>
<br>
<br>
<div style="color:rgb(0,0,0)">
<hr tabindex="-1" style="display:inline-block;
width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" color="#000000"
face="Calibri, sans-serif"><b>From:</b> sr-users
<a class="moz-txt-link-rfc2396E" href="mailto:sr-users-bounces@lists.sip-router.org"><sr-users-bounces@lists.sip-router.org></a> on
behalf of Daniel-Constantin Mierla
<a class="moz-txt-link-rfc2396E" href="mailto:miconda@gmail.com"><miconda@gmail.com></a><br>
<b>Sent:</b> 25 January 2017 14:28<br>
<b>To:</b> Kamailio (SER) - Users Mailing List<br>
<b>Subject:</b> Re: [SR-Users] Issue with From
address being modified in ACK whishen UAC module
used version 4.1</font>
<div> </div>
</div>
<div>
<p>Hello,</p>
<p><br>
</p>
<p>is the From in incoming INVITE same as in ACK?</p>
<p><br>
</p>
<p>Cheers,<br>
Daniel<br>
</p>
<br>
<div class="moz-cite-prefix">On 25/01/2017 15:16,
Jonathan Hunter wrote:<br>
</div>
<blockquote type="cite">
<div id="divtagdefaultwrapper" dir="ltr"
style="font-size:12pt; color:#000000;
font-family:Calibri,Arial,Helvetica,sans-serif">
<div>Hi Guys,</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So its just a normal call inbound, where
on outbound leg we modify the From address,
on the inbound leg all remains the same.</div>
<div><br>
</div>
<div>Now after the ingress side receives the
200ok, it sends an ACK as below;</div>
<div><br>
</div>
<div>
<div>ACK <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="sip:+441624111111@192.168.24.8:5080;transport=udp">
sip:+441624111111@192.168.24.8:5080;transport=udp</a> SIP/2.0</div>
<div>Via: SIP/2.0/UDP
4.4.4.4:5060;branch=z9hG4bK+7f5c8c756ae3b26a956b33b88c77c29f1+sip+3+aa6d1466</div>
<div>Call-ID: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im">8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im</a></div>
<div><b>From: "+44792498881474" <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="sip:+44792498881474@192.168.24.8:5080;user=phone">
<sip:+44792498881474@192.168.24.8:5080;user=phone></a>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2</b></div>
<div>To: "+<span style="">441624111111</span>"
<<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="sip:+">sip:+</a><span style="">441624111111</span>@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF</div>
<div>CSeq: 1 ACK</div>
<div>Contact: <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="sip:4.4.4.4:5060"><sip:4.4.4.4:5060></a></div>
<div>Route: <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="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-></a></div>
<div>Content-Length: 0</div>
<div>Max-Forwards: 68</div>
<div><br>
</div>
<div>However kamailio changes the From
address;</div>
<div><br>
</div>
<div><br>
</div>
<div>ACK <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="sip:+441624111111@192.168.24.8:5080;transport=udp">
sip:+441624111111@192.168.24.8:5080;transport=udp</a> SIP/2.0</div>
<div>Via: SIP/2.0/UDP
109.73.69.165:5060;branch=z9hG4bKc1ce.47974fc3da2b669a78f2dcc9a057a127.0</div>
<div>Via: SIP/2.0/UDP
4.4.4.4:5060;rport=5060;branch=z9hG4bK+7f5c8c756ae3b26a956b33b88c77c29f1+sip+3+aa6d1466</div>
<div>Call-ID: <a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im">8791dbd3855eeafd484f397de6e2f76e@carrier.peering.telecom.im</a></div>
<div><b>From: "+44792498881474" <a
moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="sip:+441444680332@es132y$%7D-9">
<sip:+441444680332@es132y$}-9></a>.8n?~9,*%(;zyk393;7e&C^NRone>;tag=carrier.peering.telecom.im+3+863d20a3+1b9801d2</b></div>
<div>To: "+<span style="">441624111111</span>"
<<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="sip:+">sip:+</a><span style="">441624111111</span>@8.8.8.8:5080;user=phone>;tag=6rrtgNFQDNrFF</div>
<div>CSeq: 1 ACK</div>
<div>Contact: <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="sip:4.4.4.4:5060"><sip:4.4.4.4:5060></a></div>
<div>Content-Length: 0</div>
<div>Max-Forwards: 67</div>
</div>
<div><br>
</div>
<div>Causing FreeSWITCH to not recognise the
request, and therefore not send an ACK.</div>
<div><br>
</div>
<div>There are no rules set against the ACK
processing.</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>Many thanks in advance.</div>
<div><br>
</div>
<div>Jon</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Kamailio Advanced Training - Mar 6-8 (Europe) and Mar 20-22 (USA) - <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
Kamailio World Conference - May 8-10, 2017 - <a class="moz-txt-link-abbreviated" href="http://www.kamailioworld.com">www.kamailioworld.com</a></pre>
</body>
</html>