11 Jan
2003
11 Jan
'03
1:41 a.m.
We have a group of people who run their own SIP servers (some are
SER, some are not) and we are going to be sharing a PSTN gateway (Cisco
box).
I need to rewrite the identities for the users of our gateway into
something that can be presented to the PSTN gateway for billing
purposes. We don't want to do that mapping on the gateway itself, for
various reasons.
How do people handle this situation? Is it wise to put all functionality
for user handling and incoming call handling and forwarding to another
place in the same SER server?
--Michael
11 Jan
11 Jan
2:44 a.m.
At 09:41 PM 1/10/2003, Michael Graff wrote:
We have a group of people who run their own SIP servers
(some are
SER, some are not) and we are going to be sharing a PSTN gateway (Cisco
box).
I need to rewrite the identities for the users of our gateway into
something that can be presented to the PSTN gateway for billing
purposes. We don't want to do that mapping on the gateway itself, for
various reasons.
I'm not sure I understand. You want to account calls to PSTN, is that
what you wish to achieve?
- why can't you account to the accounting system from the gateway
-- I think of gateways as a very good place for accounting --
they know everything about a call, including the PSTN side and
media status; they are thus in better shape to account than a proxy is
- what do you mean by rewriting identities? are you thinking of
a proxy which authenticates incoming requests from upstream
and authenticates to downstream gateway as someone else? why?
- what accounting mechanims would you like to use? radius?
Or am I guessing completely wrong and you mean you wish to have
the ability to replace a native sip user name "john.doe" with "his"
phone number 1234, so that the gateway sees "1234" as username and
can propagate it to PSTN?
How do people handle this situation? Is it wise to put
all functionality
for user handling and incoming call handling and forwarding to another
place in the same SER server?
I guess I need to understand better all the things above to answer.
Cheers,
-Jiri
5:03 a.m.
Jiri Kuthan <jiri(a)iptel.org> writes:
I'm not sure I understand. You want to account
calls to PSTN, is that
what you wish to achieve?
Yes. There are I think 4 entities who all want to share one PSTN
gateway. Each will receive a different phone bill, and may want to
present different source phone numbers to bill specific groups within
their DID.
That said, I'm new to telephone stuff, so I may be asking the wrong
questions or using the wrong words.
- why can't you account to the accounting system
from the gateway
-- I think of gateways as a very good place for accounting --
they know everything about a call, including the PSTN side and
media status; they are thus in better shape to account than a proxy is
For call length, sure, but I need to tell the PSTN gateway the source
of the call, and we don't want it to be the one mapping sip:graff@isc.org
into a 10-digit phone number.
- what do you mean by rewriting identities? are you
thinking of
a proxy which authenticates incoming requests from upstream
and authenticates to downstream gateway as someone else? why?
See above.
- what accounting mechanims would you like to use?
radius?
that, or sql, or syslog.
Or am I guessing completely wrong and you mean you
wish to have
the ability to replace a native sip user name "john.doe" with "his"
phone number 1234, so that the gateway sees "1234" as username and
can propagate it to PSTN?
Exactly. Only it will see 65077970xx, but that's beside the point.
--Michael
7:55 a.m.
New subject: [Serusers] Proxy_authorize, www_authorize
What is the difference between these two functions?
Also, when it comes to authentication, I've finally
got my PSTN secure. It seems that every request
that you want guarded must be preceeded by a
www_authorize(), right? When I ngrep for the
packets going back and forth, I see that each INVITE is
now being authorized....not just the REGISTERs.
I was assuming that you logged in and were authorized once, and
then each request was under that login. However, I see that
isn't the case, right??? You *can* make a INVITE request
without REGISTERing...right?
I'm getting older, this information takes longer to seep in :-)
---greg
8:39 a.m.
New subject: [Serusers] Weird syslog messages
I see these every now and then...
Jan 10 20:22:35 build ser[14278]: authorize(): Invalid nonce value
received, very suspicious !
Jan 10 20:22:53 build ser[14278]: is_user(): No authorized credentials
found (error in scripts)
Jan 10 20:23:28 build ser[14278]: is_user(): No authorized credentials
found (error in scripts)
Jan 10 20:40:45 build ser[14272]: db_close(): Invalid parameter value
Jan 10 20:40:56 build ser[14419]: authorize(): Invalid nonce value
received, very suspicious !
Jan 10 20:41:09 build ser[14421]: WARNING: sip_msg_cloner: header body
ignored: 4096
I think it is when I stop and start the server manually.
Should I be worried? Is there a more graceful way of restarting?
---greg
13 Jan
13 Jan
8:59 a.m.
New subject: [Serusers] Weird syslog messages
On 10-01 21:39, Greg Fausak wrote:
I see these every now and then...
Jan 10 20:22:35 build ser[14278]: authorize(): Invalid nonce value
received, very suspicious !
This either means that the client modified the nonce or you started
ser again and forgot to kill the previous instance of the server.
Jan 10 20:22:53 build ser[14278]: is_user(): No
authorized credentials
found (error in scripts)
This means you call some function from auth module and didn't call
authorize before that. Some functions from auth module need authorized
credentials and if issue this error if the message contains no authorized
credentials.
Jan 10 20:23:28 build ser[14278]: is_user(): No
authorized credentials
found (error in scripts)
Jan 10 20:40:45 build ser[14272]: db_close(): Invalid parameter value
You can ignore this one.
Jan 10 20:40:56 build ser[14419]: authorize(): Invalid
nonce value
received, very suspicious !
Jan 10 20:41:09 build ser[14421]: WARNING: sip_msg_cloner: header body
ignored: 4096
I think it is when I stop and start the server manually.
Should I be worried? Is there a more graceful way of restarting?
Use the init script distributed with ser.
regards, Jan.
14 Jan
14 Jan
4:08 p.m.
New subject: [Serusers] Weird syslog messages
At 04:59 AM 1/13/2003, Jan Janak wrote:
Just one short note on why it is this way: any processing based on digest
id (like is_user does) is only meaningful after the authenticity of digest
id was verified. Othewise any request sender could put any digest id in
request (e.g., "foobar" or "gwbush") and you would use it. Thus, call
an
authorization action first.
-Jiri
Jan 10
20:22:53 build ser[14278]: is_user(): No authorized credentials
found (error in scripts)
This means you call some function from auth module and didn't call
authorize before that. Some functions from auth module need authorized
credentials and if issue this error if the message contains no authorized
credentials. 
11 Jan
11 Jan
10:11 p.m.
New subject: [Serusers] Proxy_authorize, www_authorize
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Saturday 11 January 2003 03:55, Greg Fausak wrote:
What is the difference between these two functions?
Their are two authorization responses in SIP 401 and 407. In theory you should
receive 401 for an unauthorized registration, and 407 from a proxy in a chain
which processes for example your Invite. But i think in practice their is no
such well defined distinction what you will receive or send.
Also, when it comes to authentication, I've
finally
got my PSTN secure. It seems that every request
that you want guarded must be preceeded by a
www_authorize(), right? When I ngrep for the
packets going back and forth, I see that each INVITE is
now being authorized....not just the REGISTERs.
Correct.
The easiest and securest way is to authorize everything and to make exceptions
for special cases (responses for example).
A little bit like firewalling ;) : check only special cases and allow
everything else, or check everything and open only small holes.
I was assuming that you logged in and were authorized
once, and
then each request was under that login. However, I see that
isn't the case, right??? You *can* make a INVITE request
without REGISTERing...right?
Please be aware that a registrar and a proxy can be two completly (also
physical) seperated untis. And each unit can have it's own authorization
scheme.
A proxy can challenge Invites and Byes, but should not do this with external
Invites to your local user. Otherwise your your user wouldn't be reachable
from outside.
If you really want to control each SIP call in your network you should be
aware that your users and the SIP clients do not have to use your local proxy
and/or registrar. This means you have to forward every SIP request (and this
do not have to be only port 5060) by your outgoing router to your local
proxy.
Regards
Nils
- --
gpg-key: http://www.ohlmeier.org/public_key.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+IFBMx8PydbrWykARAvNdAJ9WThl3Z8nfQHe2PywjkXkyufZRJACdGjlo
9E6iaG/Vi9g9q4CmrkNO5rs=
=+1xN
-----END PGP SIGNATURE-----
12 Jan
12 Jan
9:49 p.m.
New subject: [Serusers] Proxy_authorize, www_authorize
Nils Ohlmeier <nils(a)ohlmeier.de> writes:
A proxy can challenge Invites and Byes, but should not
do this with
external Invites to your local user. Otherwise your your user
wouldn't be reachable from outside.
I implemented something much like this:
if (to me):
if register
www_authorize or fail if not a valid register
done
if claiming to be "From" one of the domains I accept
registrations for
proxy_authorize
done
if not to me (I'm relaying for a local phone to an external address)
proxy_authorize (once again, based on from address)
done
--Michael
10 p.m.
New subject: [Serusers] Proxy_authorize, www_authorize
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sunday 12 January 2003 17:49, Michael Graff wrote:
Nils Ohlmeier <nils(a)ohlmeier.de> writes:
Looks like a reasonable implementation to me.
Nils
- --
gpg-key: http://www.ohlmeier.org/public_key.asc
A proxy can challenge Invites and Byes, but
should not do this with
external Invites to your local user. Otherwise your your user
wouldn't be reachable from outside.
I implemented something much like this:
if (to me):
if register
www_authorize or fail if not a valid register
done
if claiming to be "From" one of the domains I accept
registrations for
proxy_authorize
done
if not to me (I'm relaying for a local phone to an external address)
proxy_authorize (once again, based on from address)
done -----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+IZ84x8PydbrWykARApwbAKC2DXYWkiPoeK+7Nnk94KknQlVh5wCg6ebW
SMPum3FJ6PNPsxwvL3KcSlo=
=SXc/
-----END PGP SIGNATURE-----
14 Jan
14 Jan
3:51 p.m.
New subject: [Serusers] Proxy_authorize, www_authorize
makes perfect sense.
-Jiri
At 05:49 PM 1/12/2003, Michael Graff wrote:
Nils Ohlmeier <nils(a)ohlmeier.de> writes:
--
Jiri Kuthan http://iptel.org/~jiri/
A proxy can challenge Invites and Byes, but
should not do this with
external Invites to your local user. Otherwise your your user
wouldn't be reachable from outside.
I implemented something much like this:
if (to me):
if register
www_authorize or fail if not a valid register
done
if claiming to be "From" one of the domains I accept
registrations for
proxy_authorize
done
if not to me (I'm relaying for a local phone to an external address)
proxy_authorize (once again, based on from address)
done
--Michael
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
3:44 p.m.
New subject: [Serusers] Proxy_authorize, www_authorize
At 03:55 AM 1/11/2003, Greg Fausak wrote:
What is the difference between these two functions?
Primarily an esthetic one. www_ should be used from user agents
(such as registrar). proxy_ from proxies. nothing bad happens
imho if use always use proxy_
Also, when it comes to authentication, I've
finally
got my PSTN secure. It seems that every request
that you want guarded must be preceeded by a
www_authorize(), right? When I ngrep for the
packets going back and forth, I see that each INVITE is
now being authorized....not just the REGISTERs.
I was assuming that you logged in and were authorized once, and
then each request was under that login. However, I see that
isn't the case, right??? You *can* make a INVITE request
without REGISTERing...right?
Yes -- there is nothing what a phone would prevent from doing so.
Each request deserves its own security.
There may still be cases in which you do not wish to insist
on authentication: calls from other domains (like "your company's
new customer is contacting you first time and has of course
no password) or from devices without digest support (like Cisco
gateways, in which case you are left to checking request's
IP address).
-Jiri
10:34 p.m.
At 01:03 AM 1/11/2003, Michael Graff wrote:
[...]
That said, I'm new to telephone stuff, so I may be
asking the wrong
questions or using the wrong words.
Don't worry, that's mostly me where confusion comes from.
I understand now -- you wish that requests From: sip:graff@isc.org
will appear to the destination as From: sip:65077970xx@isc.org so
that a gateway can propagate the number down to PSTN and use it
for accounting.
I think the right way to do this thing is to have a proxy server
attaching a "network asserted identity" (NAI) to the request. The
NAI piece of data includes then the desired number. This has
been recently discussed on the IETF/SIPPING mailing list, thread
"URIs for Gateways". The major drawback of this method is it is
still under discussion, it will take quite long to complete
(if ever, you never know in IETF).
Changing content of From header field by proxy is imho too risky and
could result in interoperability problems. Pre-3261 implementations use
from to identify transactions and dialogs. 3261 implementations only
use from-tag, but it is hard to tell which currently available
implementations really do that. Some people might be concerned too
about a possible damage to transparency, which -- similarly to
how NAT's rewrite packets and cause confusion -- might result in
confusion.
So I may be too pesimistic or ignorant, but I unfortunately only
see these imperfect options:
- account from a proxy server and use some local translation
(graff->65077970xx) during the accounting process; ignore the issue
of displaying 65077970xx down in PSTN
- use 65077970xx as SIP user id and 'graff' as an alias for incoming
request
- wait until NAI is standardized in IETF and deployed in SIP products
- rewriting From at a quite high risk of interoperability problems
What do you think?
-Jiri
15 Jan
15 Jan
1:59 a.m.
Jiri Kuthan <jiri(a)iptel.org> writes:
- rewriting From at a quite high risk of
interoperability problems
If this is only used between this specific PSTN gateway (a Cisco box)
and SER (we require it to be in the loop for this PSTN path) this may
be the fastest way. It is a 1:1 translation anyway, so we could
really say "from source SER s/graff@isc.org/65077970xx@isc.org/ and
reverse the translation on the other way (or just let it talk directly
to us, since that's not the problem direction.)
Yes, I know it's a hack, and not a long-term fix. I think the NAI
thing seems like the fix we'd want.
When is SIP 3.x coming out that fixes all the NAT, proxy, and other
protocol issues? Sorry, I'm being cynical. :)
--Michael
7:42 p.m.
<sorry>for delay, I'm travelling</sorry>
At 09:59 PM 1/14/2003, Michael Graff wrote:
Jiri Kuthan <jiri(a)iptel.org> writes:
Well, I am neither happy about IETF's pace and ignorance of issues related
to SIP operation -- vendors and marketeers are there simply ahead of operators.
I'm trying to think out how your hack would be implementable. We would have
to enforce record-routing so that subsequent transactions can be rewritten
too. A SAT module (SIP Address Translation :)) would rewrite URI in From
of both initial requests, and their replies.
It would take transaction processing as long as some transactions may be
rewritten, some not and one needs to 'remember' replies of which transactions
shall be rewritten.
We then still need to be able to rewrite transactions originated by the
called party, i.e, if called gateways send a Bye with "650" in To, it needs
to be rewritten back to "mike". The caller would otherwise very likely
not recognize the BYE as a part of an ongoing transaction. A hack to achieve
that might be use of a new record-routing parameter. The parameter would tell
"this belongs to a translated dialog and needs to be translated too".
The parameter could include the original address as well as the rewritten
one -- that would save an additional database lookup. It could look like
;satin=mike@foo.bar;satout=650@foo.bar.
If a request from caller (satin=from) hits the proxy, it now nows how to rewrite
From: without database lookup. If a request from callee arrives (satout=to), the
server knows too and rewrites To header field reversely.
does it sound reasonable?
-Jiri
- rewriting From at a quite high risk of
interoperability problems
If this is only used between this specific PSTN gateway (a Cisco box)
and SER (we require it to be in the loop for this PSTN path) this may
be the fastest way. It is a 1:1 translation anyway, so we could
really say "from source SER s/graff@isc.org/65077970xx@isc.org/ and
reverse the translation on the other way (or just let it talk directly
to us, since that's not the problem direction.)
Yes, I know it's a hack, and not a long-term fix. I think the NAI
thing seems like the fix we'd want.
When is SIP 3.x coming out that fixes all the NAT, proxy, and other
protocol issues? Sorry, I'm being cynical. :)
7774
days inactive
7779
days old
14 comments
5 participants
participants (5)
-
Greg Fausak -
Jan Janak -
Jiri Kuthan -
Michael Graff -
Nils Ohlmeier