Hi Timo,
You might be interested in checking out the commit
0f702f6e236eb0cbb238bf83a0c4ae94d7b3cad8 .
It adds an alternative implementation to the AUTO mode for uac_replace_from/to() by using the dialog module to store the URIs. Here is the excerpt from the README file explaining this:
If you set restore_mode to AUTO, the URI will be modified automatically in all subsequent requests and replies in that dialog.
There are two ways in which the AUTO mode can be achieved.
One uses the rr module and appends to the Record-Route header a parameter containing some strings from which the original and new URI can be computed. The problem with this mode is that it relies on the fact the parties will send the Route exactly as it was received. In case there is a change, the resulting URIs will not be correct.
The other one uses the dialog module to store the original and new URI. If you already use dialog module in your configuration, this is the advisable mode. All you need to do to use this is to call dlg_manage() before calling uac_replace_to(). It works by storing the URIs as dialog variables and registering callbacks in dialog module for in dialog requests.
Regards, Anca
On 07/03/2012 09: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?
Cheers, Timo
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users