21 Jan
2003
21 Jan
'03
9:30 p.m.
At 07:08 PM 1/20/2003, John Todd wrote:
Yes, I understand that mapping a single end device
works; I had that working in a few seconds, and I understand that process. However, my
goal is not to have a single device that is mapped to a single service. I'd like to
have ser make intelligent decisions on call routing, using the iconnecthere.com account
gateway as one of a number of different destinations for calls to land from any of the six
devices in my house. (with "my house" being a demo for a small office
environment)
bear with me -- I'm not sure yet I understood. Why do you need a b2bua for that?
You can have six homes at your home, all of them with iconnect credentials
configured in them, and SER can make routing decision in proxy mode. It can
tell Argentina destinations go to iconnect, US to vonage, and all extensions
beginning with 4 are for one of my six home phones. What is missing?
[...]
I think there is a minor misunderstanding, which is
probably due to my poor explanation.
Understood that ser is not a B2BUA. My goal is to re-write the calls to a B2BUA that is
statically mapped to the iconnecthere.com service as a "portal" to my account
there. (that is, of course, if I even need a B2BUA.)
Theoretical outbound call process:
Start
1) Handset picked up in my house on one of the ATA-186 units.
2) User dials 1-650-555-1212
3) Call is referred to ser process running on system in my house
4) Ser examines call like this:
a) Is the call bound for an extension elsewhere in the house?
If yes, re-route call to that extension. Break.
If no, proceed.
a) Is the call bound for a 1-503-xxx-xxxx number?
If yes, then send to local 2610 gateway into the 503 area code. Break.
If no, proceed.
b) Is the call bound for a 1-301-xxx-xxxx or 1-410-xxx-xxxx number?
If yes, then send to a Cisco 3640 with PRI interface located in Maryland, local to
those area codes. Break.
If no, proceed.
d) Send call to iconnecthere.com, using my "username" and
"password" credentials for the single account I have at their service. Break.
End
That's doable with ser in proxy mode as long as all the phones
have iconnect configured credentials in them.
To use IP terminology, the iconnecthere.com account
would be my "default route" when no other specific route is known.
My problem is part "d", where I am uncertain how to refer a call out to a
service that is expecting a UA, with a different username and password than what I have on
my local ATA-186. ser has the ability to alter the username and password on a
pass-through, but is that what I'm looking for? I can't wrap my head around that
concept when working with a system that expects a UA. Do I send the call to a B2BUA after
step 5? Is there some way of re-writing the credentials within ser?
Several solutions come into my mind, to be able to deal with
two accounts -- iconnect and your local one.
The first one I am actually using is I maintain multiple accounts in
phones -- Cisco 7960 and snom. I think I saw support for two user
accounts in ATAs but do not have one with me to verify it.
Another option is to make your local username/password same as
that which you have with iconnect.
One could have, as you propose, an identity rewriting element but
that would take a development effort. It should not be actually
difficult, but all our folks are currently busy with implementing
other, more frequently asked features.
Yes, I'd seen this in the Cisco documentation, but
as I mention in the question I'm looking for how to manage NAT addressed UA's
where the external IP address changes on a very regular basis. The link above only seems
to discuss how one can configure an ATA-186 to "hold" an external address by
sending periodic packets through the translation; this doesn't touch on how one would
get a system to work correctly after initial activation without manual intervention.
Is the server with which you are registering on the public side of NAT
or on yours?
The "via" header (and related rport
extension) seems like the solution to this problem, but does ser do the "right
thing" with those data? That is discussed a bit lower in the document under the
heading "Receiver-tagged VIA header ". I could find no reference to it in the
documentation for ser, and a brief test with NAT addressed devices did not display
successful results when the appropriate bit flag was set in the ATA-186. By examining the
source code, I do find that some features of the "received=" header are
implemented in ser, but I am unsure of their exact use and I find no mention in the source
of "rport" which has been discussed in other threads as a key to NAT RTP session
mapping.
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.
-Jiri