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

[Jeff Pyle]

Got it.

I contacted my provider, citing the third paragraph of section 12.2.1.1 of
RFC 3261 where it talks about keeping the From and To URIs the same for
compatibility with RFC 2543.  We'll see what they say.  That section goes on
to say this requirement will likely be removed in the future, using only the
tags for dialog identification.  Are there any plans to update the
uac_replace_from functions to operate once this requirement has gone away?

It seems some equipment vendors have already jumped the gun...



- Jeff



On 7/28/09 9:30 AM, "Bogdan-Andrei Iancu" <bogdan at voice-system.ro> wrote:

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