Hello
Thanks for responding. Sorry for not having properly explained. In my company, we have two types of services (currently one, but it is finalizing the second). In the current scenario, we have a Kamailio and a series of gateway that route to different suppliers.
Not to mix services, we thought that each system has its own Kamailio, this is where the problem comes, when your DID route each respective system, before it was easy, because they only had one destination where to route, but now depending the DID, will have one or other destination.
NOW:
USER -- KAMAILIO -- VARIOUS GW -- VARIOUS CARRIER
I had thought to share the gateway and routes incoming calls to a Kamailio and check that this system is and routed to the corresponding Kamailio. Another idea that occurred to me, is that each system has a number of gateway and put a Kamailio between the gateway and the carrier and decide to set this gateway route. But not that be more efficient.
I do not know which is more efficient and also know if is optimal, put a Kamailio to verify the DID and know which proxy route, rather than the current proxy is the one to do.
FIRST IDEA:
USER -- KAMAILIO1 -- \ + <-- PROXY DID INBOUND <-- VARIOUS GW <-- VARIOUS CARRIER / USER -- KAMAILIO2 --
SECOND IDEA:
USER -- KAMAILIO1 -- VARIOUS GW -- \ + <-- PROXY DID INBOUND <-- VARIOUS CARRIER / USER -- KAMAILIO2 -- VARIOUS GW --
My question was, knowing the opinion of someone who has done something similar, because I have a little wary of leaving the system in production dropped or you lose performance. I will look at the module indicated (mtree) ;-). Basically, where to locate the system, if the gateways in front of, behind, etc. Had thought it at the gateway, but not lose performance.
Best regards
2011/8/1 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
On 7/28/11 1:31 AM, Anto wrote:
Hello
It presents a problem because I do not know how to assimilate the implementation. Until now we had a design of a proxy to balance out between several gateway, but it will add another proxy for another service (other users) and use the same gateway output or perhaps different (although not that be better if divide or unify the gateway). The problem as I have with the routing entry, which is not very well how to implement it.
Now we have the design like this:
-GW ----\ / - CARRIER1 USER ------ KAMAILIO ----- GW ---- + \ - CARRIER2 -GW ----/
And becomes like this:
-GW ----\ / - CARRIER1 USER ------ KAMAILIOSERVICE1 ----- GW ---- + \ - CARRIER2 -GW ----/
-GW ----\ / - CARRIER1 USER ------ KAMAILIOSERVICE2 ----- GW ---- + \ - CARRIER2 -GW ----/
Or maybe using the same gateway.
The problem is that each carrier provides DID number (I use the same for both services). Kamailio had thought to put a gateway between the carriers and that they did check the service and send it to the corresponding gateway (in the case of the gateway separately), or put it in the proxy gateway and making checking for routing to proxy (in the case of using the same gateway). What would be better? Any recommendations on how to put this into practice?.
The biggest question that I believe is the routing table, as if this new proxy routes the traffic into and leaves her in the field via ip, also pass through the output data (I have doubts whether SIP level, following standard, you can not pass through the exit) and want it to be direct (USER -> Proxy -> GW -> CARRIER), just past the entrance.
Anyone could advise me where I could find more information to set up this scenario?. thanks and sorry for bothering you with this question ;-).
unfortunately I was not able to understand exactly what you are looking for. Are you asking hints about the best way to route calls from carriers towards users? If you control the gateways, then you can instruct there where to send the calls based on DID. Otherwise, both kamailio instances can have some did map (for example using mtree module) and route locally through location or send the calls to the other kamailio instance.
Cheers, Daniel
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda