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 annonym...@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_dlg 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:+44792498881...@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 <hunter...@hotmail.com> > *Sent:* 25 January 2017 15:37 > *To:* Kamailio (SER) - Users Mailing List; mico...@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:+44792498881...@carrier.peering.telecom.im;user=phone>;tag=carrier.peering.telecom.im+4+c538fe37+7570d4e5 > > > > > > ------------------------------------------------------------------------ > *From:* sr-users <sr-users-boun...@lists.sip-router.org> on behalf of > Daniel-Constantin Mierla <mico...@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: 8791dbd3855eeafd484f397de6e2f...@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: 8791dbd3855eeafd484f397de6e2f...@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@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 -- 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
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
