[SR-Users] uac module From header rewriting problems

[Daniel-Constantin Mierla]

On 7/3/12 5:16 PM, Timo Teras wrote:
> On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>
>> On 7/3/12 3:49 PM, Timo Teras wrote:
>>> On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla
>>> <miconda at gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> On 7/3/12 8:02 AM, Timo Teras wrote:
>>>>> Hi,
>>>>>
>>>>> I fixed some uac From rewriting issues in commit e1d1c774c9ac0b4d,
>>>>> however even with the latest versions I'm still seeing corruption
>>>>> in From headers when they are rewritten for the whole dialogue
>>>>> (from_restore_mode=auto, the default).
>>>>>
>>>>> I spent some time analyzing the problem and the problem seems to
>>>>> be connected with the fact that only the bitwise difference of the
>>>>> original and modified URI are stored (XOR).  The only purpose for
>>>>> this appears to be the idea to save only the difference in the rr
>>>>> params instead of two full URIs.
>>>>>
>>>>> However, it appears that in many cases (especially call transfer)
>>>>> the From header will be altered during dialogue. This is
>>>>> explicitly allowed in RFC 3261 § 20.20:
>>>>>       The From header field indicates the initiator of the request.
>>>>> This may be different from the initiator of the dialog.
>>>>>
>>>>> I've seen this in practise with few commercial SIP stacks.
>>>>> Sometimes the changes are minor, or even trivial - but with the
>>>>> difference encoding having even one character changed (e.g.
>>>>> case), being deleted or added will result in the whole header
>>>>> being corrupted.
>>>>>
>>>>> I'm now wondering if we should just store both URIs in the rr
>>>>> params. While taking little more space, it should fix us sending
>>>>> garbage to the wire (which usually results in dropped call as the
>>>>> remote will reject the garbage messages).
>>>>>
>>>>> Any better ideas?
>>>> it makes sense storing the entire value. Not sure if anyone else
>>>> will want to be made configurable via mod param, I will go for
>>>> simplest approach and have only the correct option, it will help
>>>> in code maintenance.
>>> Sounds good. Should probably do it for the stable branches too. I
>>> can help with some of this, if needed. You have any estimate for
>>> the fix?
>> I just expressed my opinion on how to fix it, but there is no plan
>> for me to work on it in the near future, being caught in other tasks
>> and traveling. So you can go ahead and make a patch to fix it for
>> master, then later, based on the impact, it can be backported.
> Ah. Ok. "I will go" just sounded like you'll do it. Sorry for
> confusion. I'll try to take stab at it then when I get a minute for
> it. :)
"I would go" would have been more appropriate, indeed. I can help 
reviewing when you have it, nothing else in short term unfortunately.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw