[SR-Users] uac module From header rewriting problems

[Timo Teras]

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?

- Timo