[SR-Users] uac_replace_from recovery with modified header

Daniel-Constantin Mierla miconda at gmail.com
Thu Jan 24 15:55:41 CET 2013


Hello,

I got in a similar situation quite recently. I checked the code and the 
way it was designed, leads to this behavior (because the inital value 
and the new one are XOR'ed, iirc). If it is changing the domain part, is 
not much to do. In my case was adding a useless uri parameter and I 
thought of updating the module to work only on the domain part. But it 
wouldn't have been safe in all cases, like changing also the domain 
part, so ultimately I just went for replacing the URI in first INVITE to 
present the wanted URI when ringing and for the rest of requests in 
dialog I replaced with anonymous both To and From. It worked fine for 
that case.

The latest version has support for using dialog to store the From/To 
values, so no masking within rr param. It should work fine in your case, 
I guess.

For earlier version, you can achieve more or less the same by storing 
from/to values in htable, indexed by call-id.

Cheers,
Daniel


On 1/24/13 3:22 PM, Andreas Granig wrote:
> Hi,
>
> This is a question for kamailio 3.0.x and I'm still trying to 
> reproduce this issue somehow for latest stable, but maybe it was a 
> known issue anyways which got fixed in newer versions, so I don't have 
> to dig deeper into this:
>
> There is an INVITE "A -> kamailio -> B", and kamailio does 
> uac_replace_from() to replace the display- and user-part (leaving the 
> domain-part untouched).
>
> When there's a BYE "B -> kamailio -> A", then From/To are switched, so 
> the replaced From of the INVITE becomes the replaced To of the BYE. 
> Kamailio gets that one right and tries to recover (in auto-mode) the To.
>
> However, in this BYE, B changes the domain-part of the To, which 
> should be valid, as elements are only supposed to inspect the tags of 
> From/To, right? The problem though is that when recovering the To, 
> kamailio inserts garbage into the domain part. The vsf-Parameter in 
> the Route of the BYE is definitely ok though, so that doesn't seem to 
> be the issue.
>
> Here's an example:
>
> In the INVITE,
> From: "ab12345"<sip:ab12345 at 192.168.0.12;user=phone>;tag=948a3340
> gets rewritten to
> From: "12345"<sip:12345 at 192.168.0.12;user=phone>;tag=948a3340
>
> And in the BYE,
>
> To: "12345"<sip:12345 at 1.2.3.4>;tag=948a3340
> gets rewritten to
> To: "12345"<sip:ab12345<@-%:68*0.0%12;user=phone>;tag=948a3340
>
> Note that the received To in the BYE has a different host-part than 
> what got sent out in the From of the INVITE, and when kamailio 
> recovers the To, it doesn't recover the Display-part (not sure though 
> if this is intended behaviour anyway), but it only party recovers the 
> domain-part. You can still see some artefacts of the original domain 
> (like the "68" from the second "168" octet, and the "12" from the last 
> octet).
>
> Has anyone encountered this issue before?
>
> Andreas
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
  - http://conference.kamailio.com -




More information about the sr-users mailing list