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

[Bogdan-Andrei Iancu]

Yes Jeff, this is correct.

Regards,
Bogdan

Jeff Pyle wrote:
> Hi Bogdan,
>
> I think I see what you're referring to.  The domain of the From field at
> INVITE time is not the same as the domain of the To field in the BYE from
> the upstream proxy with the PSTN gateway behind it, correct?
>
> I verified it's the PSTN gateway changing the domain, not the upstream
> proxy.
>
>
> - Jeff
>
>
>
> On 7/28/09 8:44 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:
>
>   
>> 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
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>
>