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
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.
Cheers, Daniel
On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla miconda@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
On 7/3/12 3:49 PM, Timo Teras wrote:
On Tue, 03 Jul 2012 12:16:38 +0200 Daniel-Constantin Mierla miconda@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.
Cheers, Daniel
On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla miconda@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@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. :)
-Timo
On 7/3/12 5:16 PM, Timo Teras wrote:
On Tue, 03 Jul 2012 16:23:45 +0200 Daniel-Constantin Mierla miconda@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@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
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
On Thu, 19 Jul 2012 18:00:24 +0300 Anca Vamanu anca.vamanu@1and1.ro wrote:
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.
Thanks for the heads up. Looks like it would fix my issue. And yes, I'm using dlg_manage() already. So this'd be just drop-in change.
Will test. But might be that not until next week.
Thanks!
-
Anca Vamanu -
Daniel-Constantin Mierla -
Timo Teras