Hi all,
First of all two common anonymization questions:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
Then an uac issue:
The uac module (backported to ser-0.9 with "MANUAL RESTORE" mode) works well for me in this scenario:
The group "clir" indicates anonymization, and the config looks like this:
modparam("uac", "from_restore_mode", 2) route { # ... if(is_user_in("From", "clir")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } t_on_reply("1"); t_relay(); }
onreply_route[1] { if(isflagset(7)) uac_restore_from(); }
When A calls B and A is in group "clir", the From-Header sent to B is anonymized, and responses to A are restored correctly.
But when B hangs up, the UAC of B (Cisco-ATA186 or Mediatrix 2102) changes From and To in the BYE message, so A receives the anonymized From-Header as To-Header.
This is because uac_restore_from() only restores the From-Header (as the name of the function says ;o) ), not the To-Header if there is a vsf-Parameter available. This isn't correct behaviour, is it?
Also the Cisco-ATA strips off the vsf-Parameter in the BYE-Message so it isn't available anyhow, but this seems to be a Cisco-Bug!?
Any Comments/Ideas?
Andy
wheres the backport of this, I had to route to asterisk to get this done
iqbal
On 3/17/2005, "Andreas Granig" andreas.granig@inode.info wrote:
Hi all,
First of all two common anonymization questions:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
Then an uac issue:
The uac module (backported to ser-0.9 with "MANUAL RESTORE" mode) works well for me in this scenario:
The group "clir" indicates anonymization, and the config looks like this:
modparam("uac", "from_restore_mode", 2) route { # ... if(is_user_in("From", "clir")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } t_on_reply("1"); t_relay(); }
onreply_route[1] { if(isflagset(7)) uac_restore_from(); }
When A calls B and A is in group "clir", the From-Header sent to B is anonymized, and responses to A are restored correctly.
But when B hangs up, the UAC of B (Cisco-ATA186 or Mediatrix 2102) changes From and To in the BYE message, so A receives the anonymized From-Header as To-Header.
This is because uac_restore_from() only restores the From-Header (as the name of the function says ;o) ), not the To-Header if there is a vsf-Parameter available. This isn't correct behaviour, is it?
Also the Cisco-ATA strips off the vsf-Parameter in the BYE-Message so it isn't available anyhow, but this seems to be a Cisco-Bug!?
Any Comments/Ideas?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi
wheres the backport to this, I had to use asterisk in the middle for it
Iqbal
On 3/17/2005, "Andreas Granig" andreas.granig@inode.info wrote:
Hi all,
First of all two common anonymization questions:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
Then an uac issue:
The uac module (backported to ser-0.9 with "MANUAL RESTORE" mode) works well for me in this scenario:
The group "clir" indicates anonymization, and the config looks like this:
modparam("uac", "from_restore_mode", 2) route { # ... if(is_user_in("From", "clir")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } t_on_reply("1"); t_relay(); }
onreply_route[1] { if(isflagset(7)) uac_restore_from(); }
When A calls B and A is in group "clir", the From-Header sent to B is anonymized, and responses to A are restored correctly.
But when B hangs up, the UAC of B (Cisco-ATA186 or Mediatrix 2102) changes From and To in the BYE message, so A receives the anonymized From-Header as To-Header.
This is because uac_restore_from() only restores the From-Header (as the name of the function says ;o) ), not the To-Header if there is a vsf-Parameter available. This isn't correct behaviour, is it?
Also the Cisco-ATA strips off the vsf-Parameter in the BYE-Message so it isn't available anyhow, but this seems to be a Cisco-Bug!?
Any Comments/Ideas?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hello,
On Thu, Mar 17, 2005 at 05:24:00PM +0100, Andreas Granig wrote:
Hi all,
First of all two common anonymization questions:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
Then an uac issue:
The uac module (backported to ser-0.9 with "MANUAL RESTORE" mode) works well for me in this scenario:
The group "clir" indicates anonymization, and the config looks like this:
modparam("uac", "from_restore_mode", 2) route { # ... if(is_user_in("From", "clir")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } t_on_reply("1"); t_relay(); }
onreply_route[1] { if(isflagset(7)) uac_restore_from(); }
When A calls B and A is in group "clir", the From-Header sent to B is anonymized, and responses to A are restored correctly.
But when B hangs up, the UAC of B (Cisco-ATA186 or Mediatrix 2102) changes From and To in the BYE message, so A receives the anonymized From-Header as To-Header.
This is because uac_restore_from() only restores the From-Header (as the name of the function says ;o) ), not the To-Header if there is a vsf-Parameter available. This isn't correct behaviour, is it?
uac_restore_from() does restore To, unlike the name says. You have to call it for BYE. Ahyhow, looking again over the module, there seem be some issues with handling the reply to callee's request - it should be a replace not restore. I will check these days.
Ramona
Also the Cisco-ATA strips off the vsf-Parameter in the BYE-Message so it isn't available anyhow, but this seems to be a Cisco-Bug!?
Any Comments/Ideas?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Elena Ramona Modroiu wrote:
uac_restore_from() does restore To, unlike the name says. You have to call it for BYE.
Ah, I see, it's an error in my config.
I've replaced it with:
# ... if(is_user_in("From", "clir") || search("(To|t): "Anonymous" <sip:anonymous@my.domain.*vsf=")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } # ...
Is there a simpler way to check for vsf-parameter in To-Header?
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from? Because we've devices that don't do this (they just use "sip:foo@bar;tag=1234"). I haven't found this rule in the RFC, so can you please post the section so that we can inform the vendor (it's a Mediatrix 2102) about this?
Thanks, Andy
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas Granig wrote:
Elena Ramona Modroiu wrote:
uac_restore_from() does restore To, unlike the name says. You have to call it for BYE.
Ah, I see, it's an error in my config.
I've replaced it with:
# ... if(is_user_in("From", "clir") || search("(To|t): "Anonymous" <sip:anonymous@my.domain.*vsf=")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } # ...
Is there a simpler way to check for vsf-parameter in To-Header?
The restore function checks it in the simplest way but will check first the From header and then To. Other than search, I believe it is no another way from script.
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from?
Where did I make this assumption? It is wrong, having no <> is correct and follows the RFC. But in this case, the display name must not be present.
Ramona
Because we've devices that don't do this (they just use "sip:foo@bar;tag=1234"). I haven't found this rule in the RFC, so can you please post the section so that we can inform the vendor (it's a Mediatrix 2102) about this?
Thanks, Andy
Hi,
Elena Ramona Modroiu wrote:
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas Granig wrote:
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from?
Where did I make this assumption? It is wrong, having no <> is correct and follows the RFC. But in this case, the display name must not be present.
In modules/uac/from.c:153 of the main branch you (?) say:
IMPORTANT: Since FROM hdr _must_ have all the time the tag parameter, we assume that uri is also all the time quoted by <> (which is required if the hdr has parameters).
The original From-header of the UAC doesn't contain a display name, but the module complains about missing <> ("ERROR:uac:replace_from: broken from hdr; no <>").
The From/To of the incoming BYE message is:
To: "Anonymous" sip:anonymous@my.domain.com;tag=10f88cc2f5c2579;vsf=c2lwOjAxODkwNDQ0OEB0ZX N0dm9pcC5pbm9kZS5h
From: sip:01890444815@my.domain.com;tag=899cf78f9882f5a
where sip:01890444815@my.domain.com was the To-URI in the original INVITE.
Thanks, Andy
And, if this helps, here's the From/To of the original INVITE:
To: sip:01890444815@my.domain.com From: anonymous sip:018904448@my.domain.com;tag=10f88cc2f5c2579
Andy
I had the impression that I got rid of that. I will double check.
Thanks for your attention, Ramona
On Fri, Mar 18, 2005 at 11:34:17AM +0100, Andreas Granig wrote:
Hi,
Elena Ramona Modroiu wrote:
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas Granig wrote:
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from?
Where did I make this assumption? It is wrong, having no <> is correct and follows the RFC. But in this case, the display name must not be present.
In modules/uac/from.c:153 of the main branch you (?) say:
IMPORTANT: Since FROM hdr _must_ have all the time the tag parameter, we assume that uri is also all the time quoted by <> (which is required if the hdr has parameters).
The original From-header of the UAC doesn't contain a display name, but the module complains about missing <> ("ERROR:uac:replace_from: broken from hdr; no <>").
The From/To of the incoming BYE message is:
To: "Anonymous" sip:anonymous@my.domain.com;tag=10f88cc2f5c2579;vsf=c2lwOjAxODkwNDQ0OEB0ZX N0dm9pcC5pbm9kZS5h
From: sip:01890444815@my.domain.com;tag=899cf78f9882f5a
where sip:01890444815@my.domain.com was the To-URI in the original INVITE.
Thanks, Andy
On Fri, Mar 18, 2005 at 11:34:17AM +0100, Andreas Granig wrote:
Hi,
Elena Ramona Modroiu wrote:
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas Granig wrote:
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from?
Hello, I just commited the part that should fix the <> issue. Please let me know if it works now.
Regards, Ramona
Hi again!
Elena-Ramona Modroiu wrote:
I just commited the part that should fix the <> issue. Please let me know if it works now.
Ok, thanks, the <> issue is fixed. But... :o)
Two other points:
- The original display name isn't encoded, and thus can't be restored. Could this be an issue for UACs matching the whole From-Header?
- For a subsequent request with interchanged From/To (like a BYE from the the called party) you have to *restore* the To-URI of the request and *replace* the To-URI of the response. The latter isn't supported by the module. So we'd need a uac_replace_to which can be called from a reply route. It's getting complicated here ;o)
Andy
Hi Andreas,
please see my comments inline
Best regards, Marian
Andreas Granig wrote:
Hi again!
Elena-Ramona Modroiu wrote:
I just commited the part that should fix the <> issue. Please let me know if it works now.
Ok, thanks, the <> issue is fixed. But... :o)
Two other points:
- The original display name isn't encoded, and thus can't be restored.
Could this be an issue for UACs matching the whole From-Header?
The display name must not be involved in transaction matching. If I understand correctly the RFC 3261, only the URI part of FROM must be used.
- For a subsequent request with interchanged From/To (like a BYE from
the the called party) you have to *restore* the To-URI of the request and *replace* the To-URI of the response. The latter isn't supported by the module. So we'd need a uac_replace_to which can be called from a reply route. It's getting complicated here ;o)
yes, we are aware of this bug. I already discussed with Romona about this problem and will be fixed soon.
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
I have just committed some fixes and improvements regarding the From URI replacement in UAC module. Instead of stateless approach with filtering all replies for restoring the From URI, it uses TM callback per transaction - this will reduce the the overhead due to detecting the replies of modified requests and restoring computation (no decoding is actually performed now in this case).
Also the update fixes the To URI restoring problem for replies to within-dialog requests which flow in the opposite direction - like BYE generated by callee.
Note: due to the fact that the modules/uac/docs/restore_from.patch was also updated, if you have it already applied, is better to remove the old one first (use patch -R) and than to update the module from CVS and apply again the patch.
Any feedback will be helpfully.
Ramona
[...]
Hi Andreas,
there is no explicit backport planned. Anyhow, there should be just a few changes from 0.9.0 (types and flags for headers). I will take a look these days.
Regards, Ramona
Andreas Granig wrote:
Elena-Ramona Modroiu wrote:
Any feedback will be helpfully.
I'm afraid I can't give any feedback because the new stateful approach doesn't allow easy backporting to 0.9.0 anymore. Is a official backport planned in the near future?
Thanks, Andy
Hi,
Elena-Ramona Modroiu wrote:
there is no explicit backport planned. Anyhow, there should be just a few changes from 0.9.0 (types and flags for headers). I will take a look these days.
The former version compiled well after removing the _T-suffices and adding a REQ_TYPE_CB-define in the uac-module, but do I now have to modify and apply the replace_from.patch to the tm-module too?
Andy
And: you assume that SIP-URIs are always enclosed in <> when there's a parameter appended. Where do you take this assumption from?
Where did I make this assumption? It is wrong, having no <> is correct and follows the RFC. But in this case, the display name must not be present.
Except Route headers. In Route: headers the SIP URI must be enclosed in <>. Further, if the paramter is a URI parameter, the URI must be enclosed in <>, otherwise, the parameters will be header parameters.
regards, klaus
Andreas Granig wrote:
Hi all,
First of all two common anonymization questions:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
This is bad as the callee doesn't know anymore where to send other requests (e.g. BYE).
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
subst()
IMO you can't get real anonymity without a B2B UA. if(is_user_in("From", "clir")) { t_relay to asterisk box which strips IDs }
regards, klaus
Then an uac issue:
The uac module (backported to ser-0.9 with "MANUAL RESTORE" mode) works well for me in this scenario:
The group "clir" indicates anonymization, and the config looks like this:
modparam("uac", "from_restore_mode", 2) route { # ... if(is_user_in("From", "clir")) { setflag(7); uac_replace_from("Anonymous", "sip:anonymous@my.domain"); } t_on_reply("1"); t_relay(); }
onreply_route[1] { if(isflagset(7)) uac_restore_from(); }
When A calls B and A is in group "clir", the From-Header sent to B is anonymized, and responses to A are restored correctly.
But when B hangs up, the UAC of B (Cisco-ATA186 or Mediatrix 2102) changes From and To in the BYE message, so A receives the anonymized From-Header as To-Header.
This is because uac_restore_from() only restores the From-Header (as the name of the function says ;o) ), not the To-Header if there is a vsf-Parameter available. This isn't correct behaviour, is it?
Also the Cisco-ATA strips off the vsf-Parameter in the BYE-Message so it isn't available anyhow, but this seems to be a Cisco-Bug!?
Any Comments/Ideas?
Andy
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Klaus Darilion wrote:
Andreas Granig wrote:
Is it save for anonymization to alter the Contact-Header in SER if record_route() is used to strip the username/IP? If not, how do you accomplish this correctly?
This is bad as the callee doesn't know anymore where to send other requests (e.g. BYE).
Well, maybe one could replace the contact data, like the uac module does with the From-Header, and since record_route() is used, subsequent requests will hit the proxy again where the header could be restored.
And is there a way to modify the SDP body to change the o-Field to change/remove the IP of the owner/creator?
subst()
I thought this only works with the SIP header. Thanks.
IMO you can't get real anonymity without a B2B UA. if(is_user_in("From", "clir")) { t_relay to asterisk box which strips IDs }
This is exactly what I try to avoid ;o)
Thanks, Andy
-
Andreas Granig -
Elena Ramona Modroiu -
Elena-Ramona Modroiu
-
Iqbal -
Klaus Darilion -
Marian Dumitru