blair Posted March 28, 2008 Report Share Posted March 28, 2008 Hi All, I'm hoping someone can help me. I may be being dense on the telco stuff as i'm IT by trade but have been trying many different options to get pbxnsip to behave the way I would like for interoffice trunks. A little background...We are currently running two pbxnsip servers with both linked to OCS mediation servers, Pbxnsip presently is being used as a gateway to our SIP tsp services, registration and routing to international (internet based) VOIP services and to give OCS some of the normal phone system features not currently built in to the Microsoft product. Here are the details... One server is based in Melbourne, one in Sydney, in our normal dial plans we have no issues with standard interoffice routing, however we are looking to introduce least cost routing across our WAN as a basline before we roll this out to our Seattle, Brisbane and Adelaide offices. Current standard dial plans - work fine -dial plan to trunk all calls from Melbourne server to Sydney office based extensions via Sydney trunk -dial plan to trunk all calls from Sydney server to Melbourne office based extensions via Melbourne trunk proposed - least cost routing -dial plan to send all calls from Melbourne based server to Sydney based numbers via Sydney trunk and then outbound via Sydney tsp. -dial plan to send all calls from Sydney based server to Melbourne based numbers via Melbourne pbxnsip server and then outbound via Sydney tsp. Ok, basically the issue is, when I configure the proposed configuration I need to configure the "assume that call comes from user" field for local pbxnsip server charging. When I do this, calls from interstate i.e. Sydney to Melbourne and vice versa work fine. However calls to interoffice extensions no longer work (i.e internal call from Melbourne office to Sydney office), the interstate pbsnsip server fails to recognise the call as an internal extension and attempts to route outbound via the dial plan of the assumed user. I have attempted to counteract this by changing the dialplan to "call extension" with appropriate rules but this seems to end in a hung call. In summary i would like... Melbourne to Sydney intercompany calls via WAN Sydney to Melbourne intercompany calls via WAN Melbourne to Sydney calls via Sydney pbxnsip server (over WAN) and out via Sydney gateway Sydney to Melbourne calls via Melbourne pbxnsip server (over WAN) and out via Melbourne gateway Thanks, Blair Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 28, 2008 Report Share Posted March 28, 2008 Question: Do you use direct trunks between the two offices? Then the OCS-related settings should have no effect. Quote Link to comment Share on other sites More sharing options...
blair Posted March 29, 2008 Author Report Share Posted March 29, 2008 Question: Do you use direct trunks between the two offices? Then the OCS-related settings should have no effect. Yes direct trunks between the offices, at present each pbxnsip server has 3 trunks, one to our TSP, one to the local OCS mediation server and one to the other pbxnsip server. Blair Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 29, 2008 Report Share Posted March 29, 2008 Did you see the Wiki article on OCS? http://wiki.pbxnsip.com/index.php/Office_C...ications_Server should help you to get the mediation server working. The rest should be no big issue. Quote Link to comment Share on other sites More sharing options...
blair Posted March 30, 2008 Author Report Share Posted March 30, 2008 Did you see the Wiki article on OCS? http://wiki.pbxnsip.com/index.php/Office_C...ications_Server should help you to get the mediation server working. The rest should be no big issue. Yes, OCS side of things are working fine, it just when using the "assume call comes from" option for calls between states that is an issue. Blair Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 30, 2008 Report Share Posted March 30, 2008 Yes, OCS side of things are working fine, it just when using the "assume call comes from" option for calls between states that is an issue. Yea. The problem is that the OCS has it's own way here... For non-OCS trunks you of course would not set it. At the moment it is something that just cannot be changed. At least I don't know how. Quote Link to comment Share on other sites More sharing options...
Jan Boguslawski Posted May 21, 2008 Report Share Posted May 21, 2008 Yea. The problem is that the OCS has it's own way here... For non-OCS trunks you of course would not set it. At the moment it is something that just cannot be changed. At least I don't know how. Hi, I am not sure but, the described problem might be solved since Version 2.1.6. - ReleaseNotes (Some issues and product-names were confused in the R-Notes!) As far as I remember (with versions lower 2.1.6): the background was that a "trunk to trunk call" (OCS Mediation via pbxnsip to another Trunk (sip-provider, sip-gateway, sip-pbx, etc.) will fail or the wrong source number is represented to the target trunk. Before 2.1.6 the number that is set in "assume call comes from" was given as a source number to the target trunk. Now with 2.1.6. it should give the correct caller ID which was passed on to pbxnsip via OCS Mediation Server. Btw.: Least cost routing also can be done in OCS, by using the voice properties tab's, number normalization and routes. Using 2 Location profiles (Melbourne & Sydney). The key to do this is, is understanding the "Phone pattern regular expressions". But too be honest - I still got only a few things in this topic. A developer might be a good help. Maybe this screenshot will help you. I got help from one of our developers, when doing the Normalization Rules for Microsoft CeBIT booth this year. Excuse me for the german descriptions at the patterns. I will explain them below the screenshot. Please don't count on my understanding on the patterns It confuses me everytime. But it worked, very well. 1. Translates all entered E.164 numbers (including the +) with 10 to 16 digits to E.164 - easy 2. Translates all entered none E.164 foreign country numbers with two zeros first and 9 to 30 digits to E.164 (including the +) - e.g. someone enters 001 323 865 xxxx to call the US from Germany 3. Translates all entered none E.164 numbers with one zero first and 8 to 31 digits to E.164 for Germany 49 (including the +) 4. Translates all entered internal numbers with 2 digits to the local booth main telephone number E.164 (including the +) 5. Translates all entered none E.164 numbers with 4 to 31 digits to the local Hannover City E.164 (including the +) 6. Translates all 3 digits emergency numbers (110, 112, etc.) to itself. I did this, cause I want all numbers coming out (and also in) of OCS Mediation Server should be in E.164 (beside emergency numbers). From my experience, this makes the maintenance easier. I also configured the pbxnsip accounts in E.164 and a 2 digit Alias. I also set up the AudioCodes Mediant 1000 PSTN Gateway we used, to translate everything in E.164 before it goes to pbxnsip. Last but not least, handling everything in E.164 makes the number to Name (Contact) Resolution for OCS very easy. Signaling and calling name's instead of numbers is one of the key advantages in unifed communications. The phone number pattern in the route information in this case, will force to route all calls via this route. I guess with two routes (Melbourne & Sydney) and corresponding phone number patterns, you will be able to do the least cost routing. Hope this will help you. Would be nice to hear any updates from you on this issue. Thanks in advance! Best regards, Jan Boguslawski Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.