Goal: To learn about ser in a "non-critical" and very small PBX-like environment so as to be able to understand nuances of the system in a production environment at a later date at various firms whose owners who have expressed to me a high degree of interest in SIP call routing for larger enterprise and CLEC implementations.
Sub-Goal: to make all calls into and out of my house routed via IP to alternate destinations based on ser routing configuration. I have subscribed to a long-distance plan via "iconnecthere.com", I have a PRI gateway configured at a remote location (for calls into two area codes only) and my plan is to have a Cisco 2610 with FXO card for terminating my "local" phone line. My house phones are all Cisco ATA-186 devices. Based on called number, my calls will be sent to the iconnecthere.com SIP service, the Cisco PRI gateway, or the Cisco 2610 single-line gateway. Calls will also be routed appropriately based on number called on an inbound basis from any of those three gateway systems (PRI, 2610, or iconnecthere.com)
Progress: I have phone-to-phone calling working well, and I have phone-to-PRI gateway calling working well in both directions. I have not yet received the 2610, so I do not have the single-line analog gateway running, but I don't expect any issues with that system, as I understand the Cisco implementation of inbound/outbound VOIP sessions.
Problem: My "iconnecthere.com" account is a username/password protected account which (of course) requires a UA at my side of the connection. To forward calls from the various phones in the house, I would need to have something re-write my username/password requests on the fly when they are sent out to the iconnecthere.com SIP proxies/gateways. My first assumption is that I'll need a (sigh) B2BUA to act as a gateway, running (for convenience) on the same UNIX platform as ser. After thinking about it for a while, I am uncertain if that is required, but at this point I can't determine what I need to do.
I would appreciate hints on:
a) Wether I need a B2BUA at all, and if not, what config options should I be looking at in ser?
b) If I do need a B2BUA, what would you recommend? I'm using OpenBSD as my platform, and (personally) I'd like to stay away from Java for the moment.
Continuing discussion: I could see this as a fairly useful toolkit trick for a small business who wants to replace their phone switch with SER or ser-like systems. If you've got an office with 10 people, it may make economic sense to simply get "generic" accounts with a SIP long distance gateway provider like iconnecthere.com (there are others) and allocate each of those accounts to individuals in the organization. This is not a solution for a large-scale operation for the various reasons outlined in the http://www.iptel.org/info/trends/#b2bua texts, but the number of small-scale shops out there is very large and a simply understood package (and simply billed) is what would be desired for many places who still use under ~10 analog lines for outbound dialing from their PBX. Any outbound calls to certain prefixes would always be pushed through a specific account for LD calling. Additionally, inbound calling through a similar service would have to also come in via the same mechanism, with a REGISTER request being sent by the B2BUA and all subsequent calls being routed through the SER proxy.
PS: I'd appreciate any open-source hints on how to get an ATA-186 (v2.15) running behind NAT with ser on the "outside" of the NAT, without statically configuring the "NAT" address on the ATA-186 every time the outside address changes. Lots of keyword matches found on Google, but very few clues to be scraped from the resulting documents as to "how" do it from the server side.
JT
At 08:41 PM 1/19/2003, John Todd wrote: [...]
Problem: My "iconnecthere.com" account is a username/password protected account which (of course) requires a UA at my side of the connection. To forward calls from the various phones in the house, I would need to have something re-write my username/password requests on the fly when they are sent out to the iconnecthere.com SIP proxies/gateways. My first assumption is that I'll need a (sigh) B2BUA to act as a gateway, running (for convenience) on the same UNIX platform as ser. After thinking about it for a while, I am uncertain if that is required, but at this point I can't determine what I need to do.
If you wish to authenticate with iconnect, configure iconnect credentials in you end-device, that's it. There are devices too (like Cisco 7960 or snom) that can handle multiple SIP accounts too, if you need that. That's imho simpler than inserting a middle-man authenticating on your behalf.
I would appreciate hints on:
a) Wether I need a B2BUA at all, and if not, what config options should I be looking at in ser?
see above -- maybe I missed some aspect of your scenario, but I do not currently see why you should need B2BUA. ser is not a B2BUA and cannot be configured to act so. That would take writing new code.
Additionally, inbound calling through a similar service would have to also come in via the same mechanism, with a REGISTER request being sent by the B2BUA and all subsequent calls being routed through the SER proxy.
as said, phones can register with and receive calls from servers without b2bua functionality.
PS: I'd appreciate any open-source hints on how to get an ATA-186 (v2.15) running behind NAT with ser on the "outside" of the NAT, without statically configuring the "NAT" address on the ATA-186 every time the outside address changes. Lots of keyword matches found on Google, but very few clues to be scraped from the resulting documents as to "how" do it from the server side.
http://www.iptel.org/phpBB/viewtopic.php?topic=28&forum=1&0 particularly, the second link mentions how one can set up advertising the public address in ATA's signaling. I hope we will add some more details in there.
-Jiri
At 2:34 PM +0100 1/20/03, Jiri Kuthan wrote:
At 08:41 PM 1/19/2003, John Todd wrote: [...]
Problem: My "iconnecthere.com" account is a username/password protected account which (of course) requires a UA at my side of the connection. To forward calls from the various phones in the house, I would need to have something re-write my username/password requests on the fly when they are sent out to the iconnecthere.com SIP proxies/gateways. My first assumption is that I'll need a (sigh) B2BUA to act as a gateway, running (for convenience) on the same UNIX platform as ser. After thinking about it for a while, I am uncertain if that is required, but at this point I can't determine what I need to do.
If you wish to authenticate with iconnect, configure iconnect credentials in you end-device, that's it. There are devices too (like Cisco 7960 or snom) that can handle multiple SIP accounts too, if you need that. That's imho simpler than inserting a middle-man authenticating on your behalf.
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)
I would appreciate hints on:
a) Wether I need a B2BUA at all, and if not, what config options should I be looking at in ser?
see above -- maybe I missed some aspect of your scenario, but I do not currently see why you should need B2BUA. ser is not a B2BUA and cannot be configured to act so. That would take writing new code.
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
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?
Again, if I do need a B2BUA, what would anyone suggest for a package that runs in a non-Java environment?
Additionally, inbound calling through a similar service would
have to also come in via the same mechanism, with a REGISTER request being sent by the B2BUA and all subsequent calls being routed through the SER proxy.
as said, phones can register with and receive calls from servers without b2bua functionality.
PS: I'd appreciate any open-source hints on how to get an ATA-186 (v2.15) running behind NAT with ser on the "outside" of the NAT, without statically configuring the "NAT" address on the ATA-186 every time the outside address changes. Lots of keyword matches found on Google, but very few clues to be scraped from the resulting documents as to "how" do it from the server side.
http://www.iptel.org/phpBB/viewtopic.php?topic=28&forum=1&0 particularly, the second link mentions how one can set up advertising the public address in ATA's signaling. I hope we will add some more details in there.
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.
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.
JT
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
- Handset picked up in my house on one of the ATA-186 units.
- User dials 1-650-555-1212
- Call is referred to ser process running on system in my house
- 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
At 9:30 PM +0100 1/21/03, Jiri Kuthan wrote:
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?
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.
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 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.
[...]
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
- Handset picked up in my house on one of the ATA-186 units.
- User dials 1-650-555-1212
- Call is referred to ser process running on system in my house
- 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.
See above; this might work for a single phone, but not for many UAs trying to "share" the same account at iconnect, or for multiple possible destinations outbound from ser's perspective that have username/password requirements that I cannot force to "mirror" my credentials at iconnect.
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.
The ATA-186 supports multiple accounts, but each account is tied to one of the two phone lines on the back of the unit; they cannot be "swapped" or chosen at will. One account, one line. If someone knows any differently, I'd appreciate a URL pointer on the instructions, since I've gone over the Cisco documentation fairly exhaustively at this point, though I could be missing the obvious.
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.
<Important_Part>
Understood. I seem to have a habit of making my "simple" demos things that require development. Oh well. If you or any of the other developers see an extension in the future, here are some of my wish list items:
- ability to re-write a user's (source) credentials as a function call - ability to call an external program (probably perl) to set those two variables
</Important_Part>
I'm had initially hoped that the rewriteuserpass routine (http://www.iptel.org/ser/doc/seruser.html#BUILTINREF) already did that, but upon looking at the docs it only re-writes parts of the destination URI. Watch out for naming confusion if you ever write the modules as I describe above. :-)
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:
-1) B2BUA is started, with one side ("outside") registering with iconnecthere.com and one side "waiting" for calls ("inside") The registration process is only a formality; one could launch the B2BUA from within ser the moment before a session is forwarded to it, unless you wanted to receive calls.
1) ATA-186 caller picks up phone, dials 16505551212
2) ATA-186 sends call to ser
3) ser determines (via whatever mechanism) that the call is bound for the iconnecthere.com account gateway
4) ser re-writes the destination (via the rewriteuri/rewriteuserpass routine(s)?) and directs the call to the "inside" UA of the B2BUA pair
5) the "inside" UA sees the request, and tries to create a connection to iconnecthere.com with the call details (destination number)
6) the call progress is relayed through the B2BUA back to the ATA-186
7) if the call is successful, the B2BUA can drop out of the loop and the RTP session can be established between the iconnecthere.com gateway and the ATA-186 UA
The more I look at this, the more I see a B2BUA as a kludge, and the proxy should be doing this work. I'm used to squid and related application proxies, which allow re-writes of the source AND destination, with the proxy as a middleman (though of course "source" re-writing is a little more simple with squid than with SIP, due to architectural reasons.)
*** 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. Back to my other question of "are there any B2BUA programs that aren't Vocal and are Open Source"? ***
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?
On the public side of the NAT. My goal is to extend my "home" phones to various offices for demos of ser, which will almost assuredly be in an NAT environment.
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.
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.
To your understanding (if/when Maxim's patch is sync'ed into the source) will that remove the requirement for a stund translation server?
I appreciate your time and answers.
JT
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
-
Jan Janak -
Jiri Kuthan -
John Todd