[OpenSIPS-Users] uac_replace_from() mangling the From header

[Bogdan-Andrei Iancu]

Hi Jeff,

I looked overt the trace you sent me and the problem is the not the RR 
param (as suspected), but the From URI which is changing across the 
dialog. If you look into the trace, you will noticed that the domain 
part (an IP actually) of the FROM header at INVITE time is different 
than the one from the TO header at BYE time.

The param attached to the RR header is actually a diff between the old 
and new FROM URI so, you need to have the exact value for either old, 
either new URI - in your case, this is changes, the the diff results in 
a bogus value.

Regards,
Bogdan

Jeff Pyle wrote:
> Hi Bogdan,
>
> I'm into new territory here, so I'm not 100% sure what this is supposed to
> look like.  I can tell you that when I compare the Record-Route in the
> INVITE I send to the PSTN gateway and the Route in the BYE I receive at
> tear-down time, they are visually identical with all the same fields and all
> the same values, including the vsf.
>
> You have the entire trace for your review if you like.
>
>
> - Jeff
>
>
>
> On 7/23/09 3:27 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>
>   
>> Hi Jeff,
>>
>> A common source of errors is the fact that the UAC / UAS do not properly
>> mirror the RR parameters - if you could post the trace of the entire
>> dialog, I will be able to say if it is the same or not in your case.
>>
>> Regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>>     
>>> Hello,
>>>
>>> In previous installations I've stayed away from uac_replace_from() because
>>> in many cases I've seen it mangle the From field to the point where it's out
>>> of spec.  This time I have to use it, and I'm not having much success.
>>>
>>> In addition to loading the appropriate modules, I have configured:
>>>   modparam("rr", "append_fromtag", 1)
>>>   modparam("uac","from_passwd","my_password")
>>>   modparam("uac","from_restore_mode","auto")
>>>
>>> I've read running it more than once on a transaction is bad news.  I'm not
>>> doing that.  I'm running it once, something like this:
>>>
>>>   $var(fromuri) = "sip:anonymous@" + $Ri;
>>>   uac_replace_from("anonymous", "$var(fromuri)");
>>>
>>> I place an outbound call where this logic is hit, and all is well.  It's the
>>> restore that happens on a loose-routed BYE from the network side when the
>>> far end hangs up that seems to get things a bit out of whack.
>>>
>>>
>>> The To field in this case, since it's backwards, is being restored as
>>> follows, according to ngrep:
>>>
>>> To: "Voice Lab" 
>>> <sip:9998880093 at 11.22.33.44.:5060;transport=UDP>;tag=2378b50-0-13c4-6a31
>>>
>>> What's interesting is the 11.22.33.44 address belongs to the upstream proxy
>>> that handed the call termination, not the originating one.  My CPE equipment
>>> is complaining of an extra NULL character at the end of the address, which
>>> ngrep shows above as a ".".
>>>
>>> I've tried it with variables, with static values
>>> ("sip:anonymous at anonymous.invalid")...  Something always gets mangled in a
>>> most unfortunate way.
>>>
>>> This is on Opensips 1.5.1 on sparc.
>>>
>>> Any suggestions would be most appreciated.
>>>
>>>
>>> Thanks,
>>> Jeff
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>   
>>>       
>
>
>