17 Mar
2005
17 Mar
'05
6:24 p.m.
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
17 Mar
17 Mar
6:29 p.m.
wheres the backport of this, I had to route to asterisk to get this done
iqbal
On 3/17/2005, "Andreas Granig" <andreas.granig(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
6:30 p.m.
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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
18 Mar
18 Mar
10:12 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
11:53 a.m.
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
12:11 p.m.
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas Granig wrote:
Elena Ramona Modroiu wrote:
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.
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?
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
12:34 p.m.
Hi,
Elena Ramona Modroiu wrote:
On Fri, Mar 18, 2005 at 10:53:49AM +0100, Andreas
Granig wrote:
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: 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.
12:46 p.m.
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
3:15 p.m.
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:
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: 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.
10:03 p.m.
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
21 Mar
21 Mar
1:04 p.m.
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
5:51 p.m.
Hi Andreas,
please see my comments inline
Best regards,
Marian
Andreas Granig wrote:
Hi again!
Elena-Ramona Modroiu wrote:
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.
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)
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Voice System
http://www.voice-system.ro
26 Mar
26 Mar
10:13 p.m.
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
[...]
11:10 p.m.
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
11:47 p.m.
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
18 Mar
18 Mar
3:01 p.m.
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.
11:36 a.m.
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:04 p.m.
Klaus Darilion wrote:
I thought this only works with the SIP header. Thanks.
Andreas Granig wrote:
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.
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
}
This is exactly what I try to avoid ;o)
Thanks,
Andy
7184
days inactive
7196
days old
19 comments
6 participants
participants (6)
-
Andreas Granig -
Elena Ramona Modroiu -
Elena-Ramona Modroiu
-
Iqbal -
Klaus Darilion -
Marian Dumitru