Hi, I've a multidomain OpenSer and I want to allow REFER (with authenticacion before) just in calls between users of same domain, but it's quite complex:
- userA@domainA.com INVITE's userB@domainB.com. - During the call userA@domainA.com does an in-dialog REFER.
Because the REFER is in-dialog the message is like:
-------------------- REFER sip:userB@80.98.123.23:5060 SIP/2.0 From: sip:userA@domainA.com To: userB@domainB.com Refer-To: ... ... --------------------
How can my OpenSer know which domain this REFER goes? of course the "To" header is not valid at all.
Could be a solution a SQL query to "location" table looking for the URI (sip:userB@80.98.123.23:5060) and getting the username and domain of this?
Any other option?
Thanks a lot.
El Monday 15 October 2007 09:58:36 Iñaki Baz Castillo escribió:
How can my OpenSer know which domain this REFER goes? of course the "To" header is not valid at all.
Could be a solution a SQL query to "location" table looking for the URI (sip:userB@80.98.123.23:5060) and getting the username and domain of this?
Anyway this solution wouldn't be secure since userA@domainA.com could hack its "From" header in the REFER and appears as "@domainB.com".
So I think I need to store dialog info in a table (in the 200-OK), with those info:
- "From" header domain - RURI domain - fromtag - totag - "Call-ID" header
and query this table in REFER amtching fromtag, totag and Call-ID, and just allow the REFER is "From" header and RURI domain are the same.
"Dialog" module is not valid for me since it doesn't store RURI.
Any suggestion about it? Thanks a lot.
El Monday 15 October 2007 11:25:50 Klaus Darilion escribió:
Iñaki Baz Castillo schrieb:
"Dialog" module is not valid for me since it doesn't store RURI.
really? I wonder how the dialog module can fake BYEs without storing the RURIs (learned from contact headers) -
or do you mean the original RURI?
Yes, I meen the original RURI (the only way to know the called domain).
El Monday 15 October 2007 10:13:22 Iñaki Baz Castillo escribió:
El Monday 15 October 2007 09:58:36 Iñaki Baz Castillo escribió:
How can my OpenSer know which domain this REFER goes? of course the "To" header is not valid at all.
Could be a solution a SQL query to "location" table looking for the URI (sip:userB@80.98.123.23:5060) and getting the username and domain of this?
Anyway this solution wouldn't be secure since userA@domainA.com could hack its "From" header in the REFER and appears as "@domainB.com".
Ops, there is no this issue since the "From" is checked against the auth username in "check_from()".
Then the only I need is to store dialog original URI domain.
Authentication of in-dialog requests in SIP is borken - you can not rely on the From/To headers.
klaus
Iñaki Baz Castillo schrieb:
Hi, I've a multidomain OpenSer and I want to allow REFER (with authenticacion before) just in calls between users of same domain, but it's quite complex:
- userA@domainA.com INVITE's userB@domainB.com.
- During the call userA@domainA.com does an in-dialog REFER.
Because the REFER is in-dialog the message is like:
REFER sip:userB@80.98.123.23:5060 SIP/2.0 From: sip:userA@domainA.com To: userB@domainB.com Refer-To: ... ...
How can my OpenSer know which domain this REFER goes? of course the "To" header is not valid at all.
Could be a solution a SQL query to "location" table looking for the URI (sip:userB@80.98.123.23:5060) and getting the username and domain of this?
Any other option?
Thanks a lot.
El Monday 15 October 2007 11:26:16 Klaus Darilion escribió:
Authentication of in-dialog requests in SIP is broken - you can not rely on the From/To headers.
I can rely on "From" since if I authenticate a caller and do "check_from()" I can be sure there is not spoof.
But I need to know the dialog original URI domain in order to allow or not a REFER.
Because of this issue I need to store dialog info with original URI.
Iñaki Baz Castillo schrieb:
El Monday 15 October 2007 11:26:16 Klaus Darilion escribió:
Authentication of in-dialog requests in SIP is broken - you can not rely on the From/To headers.
I can rely on "From" since if I authenticate a caller and do "check_from()" I can be sure there is not spoof.
But I need to know the dialog original URI domain in order to allow or not a REFER.
Because of this issue I need to store dialog info with original URI.
What exactly do you want to achieve? Do you want to allow REFER only intradomain?
klaus
El Monday 15 October 2007 12:12:44 Klaus Darilion escribió:
Iñaki Baz Castillo schrieb:
El Monday 15 October 2007 11:26:16 Klaus Darilion escribió:
Authentication of in-dialog requests in SIP is broken - you can not rely on the From/To headers.
I can rely on "From" since if I authenticate a caller and do "check_from()" I can be sure there is not spoof.
But I need to know the dialog original URI domain in order to allow or not a REFER.
Because of this issue I need to store dialog info with original URI.
What exactly do you want to achieve? Do you want to allow REFER only intradomain?
Exactly. - Imagine you admin a OpenSer that gives service to 2 independent companies (domain_A and domain_B). - Imagine a user_A of domain_A calls to a user_B of domain_B. - During the call user_A does REFER. - OpenSer requires auth por REFER, so user_A sends auth (it can since it's a local user). - So finally user_B is transferred by an external user. Of course this is not tolerable.
So I need to allow a REFER just if the caller and called are in the same domain, but REFER is in-dialog so there is not domain name in the URI.
That's the issue I try to solve.
Thanks.
El Monday 15 October 2007 16:02:25 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
- So finally user_B is transferred by an external user. Of course
this is not tolerable.
if user A in one domain is able to call user B in another domain, i don't understand why it is not tolerable that user A sends a REFER to user B.
Imagine user_B uses a Linksys or any other deskphone (most of them allow incoming REFER without asking permission to the user).
- user_B@domain_B calls to PSTN number of domain_A. - Our OpenSer via ENUM query determines the target is user_A@domain_A. - The call is established. - Now user_A@domain_A sends a REFER with "Refer-to: 004598623435@domain_B". - user_B@domain_B phone is automatically referred to an internacional PSTN number via our OpenSer with no knowledge of user_B. - The international call is answered and tarified to domain_B account.
I do see a problem.
Regards.
Iñaki Baz Castillo writes:
- Now user_A@domain_A sends a REFER with "Refer-to: 004598623435@domain_B".
- user_B@domain_B phone is automatically referred to an internacional PSTN
number via our OpenSer with no knowledge of user_B.
- The international call is answered and tarified to domain_B account.
I do see a problem.
there is a problem, but the problem is with B's sip phone if it acts on refer without confirmation from the user.
how is that problem less, if A and B are in the same domain?
-- juha
El Monday 15 October 2007 17:26:29 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
- Now user_A@domain_A sends a REFER with "Refer-to:
004598623435@domain_B". - user_B@domain_B phone is automatically referred to an internacional PSTN number via our OpenSer with no knowledge of user_B.
- The international call is answered and tarified to domain_B account.
I do see a problem.
there is a problem, but the problem is with B's sip phone if it acts on refer without confirmation from the user.
I know no deskphone asking the user for permission for a REFER. I think REFER is intented to use with a B2BUA in the middle (as Asterisk for example) so external user calls with your B2BUA and B2BUA with local user. An external user is not allowed by B2BUA to send a REFER, just local users.
But of course it's simply possible a real and direct SIP communication between an external and internal user.
how is that problem less, if A and B are in the same domain?
When I say "domain" I mean "company". I understand that is allowed.
Regards.
El Monday 15 October 2007 19:05:05 Juha Heinanen escribió:
Iñaki Baz Castillo writes:
Snom 360 does.
And Twinkle softphone, but most SIP devices don't do it :(
also nokia n and e series phones ask confirmation.
Maybe I should say "most devices I've tested" ;)
Iñaki Baz Castillo wrote:
El Monday 15 October 2007 12:12:44 Klaus Darilion escribió:
What exactly do you want to achieve? Do you want to allow REFER only intradomain?
Exactly.
- Imagine you admin a OpenSer that gives service to 2 independent companies
(domain_A and domain_B).
- Imagine a user_A of domain_A calls to a user_B of domain_B.
- During the call user_A does REFER.
- OpenSer requires auth por REFER, so user_A sends auth (it can since it's a
local user).
- So finally user_B is transferred by an external user. Of course this is not
tolerable.
So I need to allow a REFER just if the caller and called are in the same domain, but REFER is in-dialog so there is not domain name in the URI.
just an idea: check if $fd of REFER is identical to domain in REFER to header - if not -> reject it.
Further, if B's phone send out the new INVITE, if $rd != $fd then do not send the call to the gateway.
regards klaus
El Monday 15 October 2007 22:35:34 Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
El Monday 15 October 2007 12:12:44 Klaus Darilion escribió:
What exactly do you want to achieve? Do you want to allow REFER only intradomain?
Exactly.
- Imagine you admin a OpenSer that gives service to 2 independent
companies (domain_A and domain_B).
- Imagine a user_A of domain_A calls to a user_B of domain_B.
- During the call user_A does REFER.
- OpenSer requires auth por REFER, so user_A sends auth (it can since
it's a local user).
- So finally user_B is transferred by an external user. Of course this is
not tolerable.
So I need to allow a REFER just if the caller and called are in the same domain, but REFER is in-dialog so there is not domain name in the URI.
just an idea: check if $fd of REFER is identical to domain in REFER to header - if not -> reject it.
It's a great idea! Of course I need to test it. For example: What about if the "Refer-to" header just contains "sip:001234234234" with no @domain? maybe there are "broken" SIP devices which auto-complete this URI with their domain?
Further, if B's phone send out the new INVITE, if $rd != $fd then do not send the call to the gateway.
Humm, it can't be, because in case of a forwarding (implemented in OpenSer) I do allow calls from others domain to PSTN gateway.
Thanks a lot for your suggest, it's a very good solution :)
Iñaki Baz Castillo wrote:
El Monday 15 October 2007 22:35:34 Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
El Monday 15 October 2007 12:12:44 Klaus Darilion escribió:
What exactly do you want to achieve? Do you want to allow REFER only intradomain?
Exactly.
- Imagine you admin a OpenSer that gives service to 2 independent
companies (domain_A and domain_B).
- Imagine a user_A of domain_A calls to a user_B of domain_B.
- During the call user_A does REFER.
- OpenSer requires auth por REFER, so user_A sends auth (it can since
it's a local user).
- So finally user_B is transferred by an external user. Of course this is
not tolerable.
So I need to allow a REFER just if the caller and called are in the same domain, but REFER is in-dialog so there is not domain name in the URI.
just an idea: check if $fd of REFER is identical to domain in REFER to header - if not -> reject it.
It's a great idea! Of course I need to test it. For example: What about if the "Refer-to" header just contains "sip:001234234234" with no @domain? maybe there are "broken" SIP devices which auto-complete this URI with their domain?
Further, if B's phone send out the new INVITE, if $rd != $fd then do not send the call to the gateway.
Humm, it can't be, because in case of a forwarding (implemented in OpenSer) I do allow calls from others domain to PSTN gateway.
Usually, if a client wants to dial a phone number, the client will add its own domain as RURI domain. E.g.
sip:client@mydomain.com calls PSTN 12345: RURI=sip:12345@mydomain.com -> forward to PSTN gateway
sip:client@mydomain.com calls sip:12345@otherdomain.com --> forward request to otherdomain. Regardless if otherdomain.com is hosted in the same openser or any others SIP proxy, at otherdomain.com this is an incoming SIP call from an external SIP client which MUST NOT be routed to the PSTN.
Thus, I would add both checks.
regards klaus
El Tuesday 16 October 2007 11:33:47 Klaus Darilion escribió:
Further, if B's phone send out the new INVITE, if $rd != $fd then do not send the call to the gateway.
Humm, it can't be, because in case of a forwarding (implemented in OpenSer) I do allow calls from others domain to PSTN gateway.
Usually, if a client wants to dial a phone number, the client will add its own domain as RURI domain. E.g.
sip:client@mydomain.com calls PSTN 12345: RURI=sip:12345@mydomain.com -> forward to PSTN gateway
sip:client@mydomain.com calls sip:12345@otherdomain.com --> forward request to otherdomain. Regardless if otherdomain.com is hosted in the same openser or any others SIP proxy, at otherdomain.com this is an incoming SIP call from an external SIP client which MUST NOT be routed to the PSTN.
Thus, I would add both checks.
But imagine this case:
- domain_A and domain_B are hosted in my OpenSer (but totally independents).
- sip:user_A@domain_A calls sip:user_B@domain_B
- In OpenSer there is forwarding: sip:user_B@domain_B -> sip:012345@domain_B
- In domain_B permissions table I allow forwardings to PSTN for calls made from others domain (as domain_A), but not direct INVITE's (of course).
- Finally sip:user_A@domain_A calls sip:012345@domain_B but I know in OpenSer it's a allowed forwarding so add any header (Diversion?) the gateway to know it and facture to sip:user_B@domain_B isntead of sip:user_A@domain_A.
- In fact, in the gateway I will facture based on RURI instead of "From".
Is not correct?
Iñaki Baz Castillo wrote:
El Tuesday 16 October 2007 11:33:47 Klaus Darilion escribió:
Further, if B's phone send out the new INVITE, if $rd != $fd then do not send the call to the gateway.
Humm, it can't be, because in case of a forwarding (implemented in OpenSer) I do allow calls from others domain to PSTN gateway.
Usually, if a client wants to dial a phone number, the client will add its own domain as RURI domain. E.g.
sip:client@mydomain.com calls PSTN 12345: RURI=sip:12345@mydomain.com -> forward to PSTN gateway
sip:client@mydomain.com calls sip:12345@otherdomain.com --> forward request to otherdomain. Regardless if otherdomain.com is hosted in the same openser or any others SIP proxy, at otherdomain.com this is an incoming SIP call from an external SIP client which MUST NOT be routed to the PSTN.
Thus, I would add both checks.
But imagine this case:
domain_A and domain_B are hosted in my OpenSer (but totally independents).
sip:user_A@domain_A calls sip:user_B@domain_B
In OpenSer there is forwarding: sip:user_B@domain_B -> sip:012345@domain_B
In domain_B permissions table I allow forwardings to PSTN for calls made
from others domain (as domain_A), but not direct INVITE's (of course).
In this case - if it is an explicit forwarding, and it will be proper accounted, then of course it is ok.
regards klaus
- Finally sip:user_A@domain_A calls sip:012345@domain_B but I know in OpenSer
it's a allowed forwarding so add any header (Diversion?) the gateway to know it and facture to sip:user_B@domain_B isntead of sip:user_A@domain_A.
- In fact, in the gateway I will facture based on RURI instead of "From".
Is not correct?
El Tuesday 16 October 2007 14:09:26 Klaus Darilion escribió:
But imagine this case:
- domain_A and domain_B are hosted in my OpenSer (but totally
independents).
sip:user_A@domain_A calls sip:user_B@domain_B
In OpenSer there is forwarding: sip:user_B@domain_B ->
sip:012345@domain_B
- In domain_B permissions table I allow forwardings to PSTN for calls
made from others domain (as domain_A), but not direct INVITE's (of course).
In this case - if it is an explicit forwarding, and it will be proper accounted, then of course it is ok.
Thanks. Let me a question about this forwardings and accounting since I'm designng it just now and have a doubt:
The gateway will be in fact other OpenSer+CDRtool+MediaProxy (if I can configure it) or Asterisk. They will contact with the real SIP carrier.
So when user_B@domain_B calls sip:12345@domain_B it will appear in OpenSer gateway: - From=user_B@domain_B - RURI=12345@domain_B
But in the aboved explained forwarding it will appear - From=user_A@domain_A - RURI=12345@domain_B
I'm not sure then how to invoice this call. I see 2 options:
a) Invoice always based on RURI [*]
b) Add a "Diversion" (or other custom) header in main OpenSer so OpenSer gateway will invoice to the user in that header.
I need to think long time about it, but I'd like to know opinions about it.
Really thanks a lot for your help.
Iñaki Baz Castillo wrote:
El Tuesday 16 October 2007 14:09:26 Klaus Darilion escribió:
But imagine this case:
- domain_A and domain_B are hosted in my OpenSer (but totally
independents).
sip:user_A@domain_A calls sip:user_B@domain_B
In OpenSer there is forwarding: sip:user_B@domain_B ->
sip:012345@domain_B
- In domain_B permissions table I allow forwardings to PSTN for calls
made from others domain (as domain_A), but not direct INVITE's (of course).
In this case - if it is an explicit forwarding, and it will be proper accounted, then of course it is ok.
Thanks. Let me a question about this forwardings and accounting since I'm designng it just now and have a doubt:
The gateway will be in fact other OpenSer+CDRtool+MediaProxy (if I can configure it) or Asterisk. They will contact with the real SIP carrier.
So when user_B@domain_B calls sip:12345@domain_B it will appear in OpenSer gateway:
- From=user_B@domain_B
- RURI=12345@domain_B
But in the aboved explained forwarding it will appear
- From=user_A@domain_A
- RURI=12345@domain_B
I'm not sure then how to invoice this call. I see 2 options:
a) Invoice always based on RURI [*]
b) Add a "Diversion" (or other custom) header in main OpenSer so OpenSer gateway will invoice to the user in that header.
I would use b). Add a header to the INVITE sent to GW-Openser (name it as you like, e.g: X-Billing-Party: ) and in GW-Openser use this header for accounting. Further: - make sure to remove every X-Billing-Party header from messages routed by the main proxy - do not accept INVITEs without this header in the GW-Openser.
This way you can be sure that nobody bypasses your accounting logic.
regards klaus
I need to think long time about it, but I'd like to know opinions about it.
Really thanks a lot for your help.
El Tuesday 16 October 2007 15:16:31 Klaus Darilion escribió:
Iñaki Baz Castillo wrote:
The gateway will be in fact other OpenSer+CDRtool+MediaProxy (if I can configure it) or Asterisk. They will contact with the real SIP carrier.
So when user_B@domain_B calls sip:12345@domain_B it will appear in OpenSer gateway:
- From=user_B@domain_B
- RURI=12345@domain_B
But in the aboved explained forwarding it will appear
- From=user_A@domain_A
- RURI=12345@domain_B
I'm not sure then how to invoice this call. I see 2 options:
a) Invoice always based on RURI [*]
b) Add a "Diversion" (or other custom) header in main OpenSer so OpenSer gateway will invoice to the user in that header.
I would use b). Add a header to the INVITE sent to GW-Openser (name it as you like, e.g: X-Billing-Party: ) and in GW-Openser use this header for accounting. Further:
- make sure to remove every X-Billing-Party header from messages
routed by the main proxy
- do not accept INVITEs without this header in the GW-Openser.
This way you can be sure that nobody bypasses your accounting logic.
Ok, thanks a lot again for your help.
Best regards.
-
Andreas Granig -
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion