At 07:45 AM 1/22/2003, John Todd wrote:
Well, it can redirect appropriately, but it cannot do
quite what you say above. If I use your method
below, and configure all my ATA-186 systems with the same username/password as I have at
iconnect, then > calls being routed to vonage (or other username/password protected
path) will not work.
That's like with webservers or any other services (gas, water, etc.) -- you typically
have separate bussiness relationships with all the service providers and identify
yourself with separate passwords. You (or your phone) need to remember all of them.
If your phone does not have the multi-account ability (like apparently ATA does
not have), there are two choices:
- junk the phone (which is what I would do :)
- introduce a password aggregation mechanism in a proxy server, like you suggest
(I'm not sure I like giving my "keyring" to a server who will
act on my behalf; for sake of completeness: there are some web
services that do it, and it is implementable for SIP too)
Plus, if I configure all my ATA-186 phones with the
same username/password as I have with iconnect, then inbound calls won't work since
every phone will be registering with my local ser process with the same credentials.
I'm not sure I understood this one -- if you have six phones sharing
one iconnect account, how do you want to distribute incoming calls to
the iconnect number? (If you have the "multiple-account" feature in
your phones, people can reach you at your local accounts too, which
are individually linked to each of your phones.) Am I still missing
something?
I may not need a B2BUA to perform this duty, but I am
used to the application proxy world (squid) which leads me to think that I'd need to
have some intermediate "funnel" which accepts inbound calls from anything on my
"local" network and redirects to a single destination on the other side in a
blocking (single-call) or non-blocking fashion.
However we call this beast ("credentials-mangling-proxy"?) -- it needs
to be little a bit more than transaction-stateful. That's because of
how SIP/digest challenge-response protocol works. It is more complex
than basic authentication -- that's the price for more security.
'rewriteuserpass' worked for basic, which has been deprecated. Briefly,
more security==more complexity, rewriting digest authentication is not
as easy as rewriting a header field.
When a challenge from provider arrives, it needs to remember it for subsequent
resubmission of the original request. When the resubmission appears, it must
be correlated to the previous transaction, credentials need to be calculated
using the stored challenge and inserted in the message.
---INV--> CMP P(rovider)
---INV--->
<---407/P--- (CMP remembers challenge)
---ACK-->
<--407/C---
---ACK--->
---INV/C---> (CMP looks up previous transaction, the challenge,
calculates credenetials, and inserts them)
----INV/P---->
So the missing pieces in ser would be keeping provider's passwords,
keeping provider's challenges, calculating and rewriting credentials.
It may still result in issues, for example if your provider likes to
have a policy From_username==digest, in which case you would have to
deploy From rewriting too. (Discussed on this list too, in past.)
I noted your request for improvement and put it on my to-do list.
Unfortunately, there are other competing items and the to-do list
is actually becoming a sort of repository of things unlikely to be
done soon if ever.
[...]
This gets me back to having this done via a B2BUA,
where one UA is talking to the remote server as an authenticated user (in my case, to
Deltathree's
iconnecthere.com service) and one side of the UA is talking to ser as a
"known" destination.
Let me think out loud here a bit:
[...]
routing is trivial. It is the digest mechanism, which costs most effort.
***
On a slightly different track but related to my quest: how does SER (or any proxy) handle
the collection of inbound calls from external agents that are expecting a UA? As an
example, let's say I have an account with
iconnecthere.com,
vonage.com, and I am a
member of INOCS-DBA (which is a VOIP-only SIP network.) All three of those services
expect me to sign in with a UA, and they all provide me with a username and password for
my UA. None of them are willing or able to send calls to me as anything other than a
registered UA. However, I don't want three phones on my desk, or three UAs running on
my desktop, or whatever. I want one phone on my desk, and all the inbound calls from all
three providers directed towards my single phone. That phone is connected to an ATA-186.
I run ser in order to gateway my outbound calls. How do I handle those three inbound
services with ser or some combination of other programs? (PS: this is not a theoretical
example; I have all three services at the moment, and I am very unhappy with the three
ATA-186 devices and phones on my desk.) This sounds like the ugly job of a B2BUA.
To me, it still sounds like an ugly job of buying a better phone. All in all,
one 7960 is no mroe expensive than three ATAs, gives you the ability to register
with six accounts, and a beatiful display.
Back to my other question of "are there any
B2BUA programs that aren't Vocal and are Open Source"?
***
I'm not aware of such, and even if there is a b2bua, it is not
clear it has support for credential rewriting.
[...]
We currently
support "received" and do not support "rport".
"rport" has been introduced with a Maxim's patch, which will in
some form make it to the next release.
It also seems that stund (
http://www.vovida.org/downloads/stun/) would help me, but I am
in the oft-unloved (but IMHO more secure) *BSD world, which precludes compiling the Vovida
stund package due to various errors which I am untrained to correct.
The stun support must be first present in the phones. Stun is useless with
stun-less phones.
To your understanding (if/when Maxim's patch is
sync'ed into the source) will that remove the requirement for a stund translation
server?
Partially. With rport/received you still need to configure your NAT
manually for port translation. stun gives you the hope you don't have
to do that. (but it does not work for symmetric NATs)
-Jiri