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

[Jeff Pyle]

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
>> 
>>   
>