mercredi 18 février 2009 00:12For the life of me I cannot get OCS R2 to add the external access prefix to a number I'm dialing.
Or national dialplan has a 0 and then 9 digits (the first one not being a zero).. so my normalization rule has the following pattern:
So, if I dial 0123456789 the output is 0123456789 just as I want it. However, I want OCS to add a leading zero before sending the call to the mediation server. So, in the location profile, I checked "Optimize device dialing" and set the "External access prefix:" to 0.
So, when I dial 0123456789 in my MOC I expect it to show just that number, but the INVITE that comes out of mediation server should be 00123456789. Well.. it isn't.. it's still 0123456789.. and my gateway (another PBX which expects a 0 as outside line prefix) refuses to let the call go forward.
Likewise for my international call pattern which is
the number goes out as is. I even went as far as to restart the frontend (does it have to be?).
Also, I tried another approach.. not using "Optimize device dialing" but instead use the "Use translation when dialing from device" option in a normalization rule. Am I correct assuming that this means that a rule would only be applied on OCS and not MOC? If say I change my first rule to rexpect
and Use translation when dialing from device is checked, I figure when I type 0123456789 MOC should show me 0123456789 (and then unfortunately we have a double normalization as OCS picks up my international rule and adds another 0) but suppose I scrap my international rule.. then I go back fro the rexpect 00$1 to 0$1.. if I restart MOC and type 0123456789 it still normalizes (adds the leading zero.... if I wait long enough (maybe 15 minutes or so).. it stops to do so. How can I get MOC to immediately apply the latest changes I made to the location profile? I even tried restarting the frontend. again it does nothing.
So I'm left scratching my head.. for starters I'd like MOC to start doing what I configure right away, and then I think either I misunderstand what those two options are supposed to do or they don't work.
@edit: to make matters even more infuriating, it seems even OCS doesn't know about his own rules.
Right now I have rule 1:
So, in moc 0123456789 turns into 00123456789 (even though "Use translation when dialing from device" is unchecked.
If I have no other rule the call fails and OCS tells me there's no matching rule. So I quickly added a bypass rule in position 2.
That should forward the number untouched
Make the call again.. still returns no matching rule found. As I typed this I logged in again and voila.. it works. Then I removed the rule again and tried again.. now it should fail but it work. Logged out and in again.. still works. So how do I get my rule changes taken into account right when I press apply? A minute later.. call still goes out even though it shouldn't (and I did another logout login cycle). Restarted MOC.. same story.
Toutes les réponses
mercredi 18 février 2009 03:41ModérateurNormalization rules are passed to the client via the Address Book. If you are trying to force changes down to the client right away you need to update the address book (abserver -syncnow), wait for it to complete (check the event log), and then logout and back in to Communicator. Sometimes it's necessary to manually delete the existing address book file galcontacts.db, which can be found in %localappdata%\microsoft\communicator (R1) or %localappdata%\microsoft\communicator\sip_<sipaddress>.
Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
mercredi 18 février 2009 10:27Alright.. that's one bit of the puzzle. However, only one bit. What about the server? Shouldn't it immediately take changes into account? Say if I delete a rule that permitted dialing out before.. should I immediately be unable to dial out even if I keep MOC running and it still has the old rules that are no longer valid?
Do you know if my understanding of "Optimize device dialing" and "Use translation when dialing from device" is correct?
lundi 14 septembre 2009 19:07Stephan - curious to know how you made out here? The documentation doesn't do an adequat job at explaining this check box and how it actually works. Ideally you would never normalize a number to have the leading PSTN code show up. This would be for the gateway or PBX to handle but you sometimes have to do this depending on the PBX you are working with.
Would be interested to know if you got this working and what the actual behaviour was of the function.
lundi 19 octobre 2009 12:28Dino.. I don't have the references before me anymore but it seems the optimize for device dialing is meant for Tanjay devices and has nothing to do with MOC as such.
That said, no I'm afraid I never came up with a satisfactory solution.. the whole "+ is the final answer to any and all call normalization" approach is so deeply ingrained that I don't think there's a way... and to make matters worse the same rules apply on client and server, and you can't have different rules for caller and callee. Your best case is if you connect to a Cisco CallManager 7 or a system with similar formating capabilities.. using that you can merrily pass the + along and clean things up on the other end of the SIP trunk. As we connect to an Alcatel PBX who has severe limitations on digit manipulation on private SIP trunks, we settled on passing the display name along - but that still means you cannot call back from the call log.
I figure the only solution would be running some custom script on the mediation which performs normalization the way you want it.. but I haven't had time to look into that subject at all.
lundi 19 octobre 2009 16:37Doug has written a great article on why using E164 in OCS is the best option.
Normalization is a tricky topic. Two places normalization occurs. First is the address book which normalizes users directory information in AD. This allows the calling from the address book in OC in the format you out line in normalization rule text file which is used during address book syncing (sorry I cant provide a reference right now for some reason I cant pull up the technet page). The second is the normalization rules you are referring to under location profiles in the OCS voice dialplan. These rules affect when you type a number directly into communicator or on a Tanjay. To pick up new location profile normalization rules you may need to sign in and out of communicator. This is also true for getting a fresh copy of the address book after you have completed syncing it.
Within OCS I would recommend E164 number format and at you gateway make any adjustments to satisfy local call routing to either a PBX or service provider. Pretty much all OCS certified gateways allow you to do this. You can remove the + at the mediation server if you are trying to interop with a PBX. If the PBX your working with is not certified your best answer maybe to use a gateway between the two environments to provide you more flexibility with digit manipulation unless your PBX can satisfy it. Maybe not the answer your looking for but if you choose not to use E164 format things may or may not work. If you must send things to your PBX as you have explained try adding the + to the leading digit and stripping it at the mediation server using the WMI setting. Make sure your route you configure in OCS also specifies the +. This is really a work around that maybe or may not be successful but if you are stuck and cant purchase a qualified gateway this may be worth a try.
You are correct that "optimize for device dialing" isn't explained very well but it is only meant for the Tanjay device.
lundi 19 octobre 2009 17:47I don't necessarily disagree that it's good to start with E.164 numbers, yet Dog's background seems to come from major national or international corporations.
Where I'm from, more and more we tend to see traditional PBXes migrating to single node and single PSTN access location models (well, the physical accesses could be at different locations but the numbering plain is uniform over the entire company - regardless of your physical location) - and that makes the whole expansion criteria moot (especially when the backbone of the local economy sits on small and medium enterprises and in Switzerland that means fewer than a 100 employees).
Since OCS relies on a 1:1 mapping of Mediation Server and gateway, there's no logical explanation for why the Mediation in itself shouldn't be capable to do the nationalization (rather than the gateway).. gateways and OCS right now are completely separate and require two completely different skillsets (not unlike Cisco CallManager.. and guess what one of the major causes for trouble is in the Cisco world.. you have a web based administration page where you can do pretty much anything, then the cli based router where you, again, can do pretty much everything so it's hard to keep everything in synch). It would be much easier of a gateway was considered to be a dumb protocol changer.. from ISDN to SIP and back and that's that.
Even when you deal with direct SIP interconnects.. I've been using SIP providers myself for the past 3 years and the majority of them doesn't do E.164 - so when it comes to OCS if you want to go down the SIP route, you need another SIP proxy in between just because Microsoft didn't allow the mediation server to do any kind of number normalization and instead forces you to normalize to E.164.
And when you have OCS behind an existing PBX but still want to go down the SIP route, hardly any PBX today is flexible enough to do the denationalization as required - so you end up having to sell a QSIG gateway just because of that, which adds cost (not only the gateway, but those E1 links don't come cheap either), administrative complexity and you have yet another point of failure.
last but not least, OCS is the only PBX I know (and I know a bunch by now) where you can change number normalization and it isn't immediately applied. My colleagues working on traditional PBXes were laughing their pants off when they heard that.. And while we're at that.. when you look at distributed large enterprises, the lack of localized redundancy is another thing you'll find with anybody but OCS.
lundi 19 octobre 2009 20:58So I just wanted to let you know what you could do right now. Standidisng on E164 does set you for the future as the standard becomes more widely accepted. I agree the mediation server should do transaltions with less reliance on the gateway but at the moment it is what it is and Microsoft are not alone in this approach. I also mentioned some possible work arounds. The + is the key.
The OCS developers are well aware of the local redundancy issue, I would look to the next release to see this resolved. Same goes for the one:one relationship for outbound from the medaition server to a gateway. Inbound to the mediation server from a gateway is a different story although its not mentioned in documentation. This is handy info for doing mediation server upgrades and pointing multiple gateways at one medation server for inbound OCS calls while upgrading a second.
As for the PBX guys, ask them the last time a analog phone did IM, Presence, application sharing, as well as the normal audio peer to peer and conferencing. Guess what, they cant. In the end companys will move to things that provide more business value (OCS or other) rather than just a single threaded offering like the traditional PBX. So while they are laughing now I can bet they will be looking for new jobs in the future:) Hate to be mean but if they dont hurry and open their eyes their jobs will be gone and unless they upgrade their skills they will be gone as well.
mardi 20 octobre 2009 16:39Even if you get rid of the + (which you can do by the way directly without using the hidden configuration option.. it is possible to de-normalize numbers for egress as long as you can live with a messed up caller number being presented on the other end), the gateway still needs additional logic, especially when you're connecting to an existing PBX.
And, hate to break it to you, but traditional PBX makers today all do unified messaging, presence, IM, application sharing, peer to peer audio from softphones and conferencing. Avaya, Alcatel-Lucent, Cisco, Nortel, Siemens all have their own solutions. OCS has somewhat of a head-start when it comes to federation but the others are catching up there, too. An integrated management sometimes is lacking, too, but that can be worked around by writing your own provisioning app (that's where I come into the picture.. and that's why I know pretty well what other manufacturers can do).
mardi 20 octobre 2009 18:12Removing the + through WMI is the only supported configuration at the mediation in support of E164. I am aware of other ways to do this but moving forward these "other ways" may or may not work. So I agree that the mediation server could do with some additional logic how this evolves we will see. Certainly getting involved with MS to explain your needs through MS advocacy groups is one way to do. If you are not already doing that I would encourage you to do so as you have very valid points.
I think if you reread my post I am not disagreeing with your statement on other manufactures more the attitudes of the telecom people working it. I currently work in a telecom group and one thing they seem to have trouble with getting there head around is voice doesn't always mean a phone, although they are getting there. I am well aware of the offerings of other companies and where I work we use quite a few of them not just OCS. Lastly I dont think you would call Cisco a traditional (traditional to me implies Analog/ISDN PBX which is something Cisco never did even though they have components that do those functions) PBX manufacture and there is pretty much is no Nortel any more which is a pitty for the industry and their customers.
mercredi 21 octobre 2009 15:47
Normalization rules it's like puzzle, it up for your design with your network and who will Normalize the call
To effect for any change you have to restart Front-end services and logout and login your MOC
For the command line ABServer –syncnow it’s use to force update for MOC Extension
You have to be aware with who you Call flow , if you want to do internal call inside from MIC to IP Phone or From IP Phone to MOC
The mediation Remove (+) there is patch for it .
So then you call from MOC to another XXX , the package will be clear without (+).
So if you want to call mobile 012XXXXXXX the MOC will normalize it to +012XXXXXX and Medication will remove (+) .
The media getaway received 012XXXXXX what is your configuration on it ??
And what is your configuration on PBX ??
You can do more puzzle here….
If No (0) mean external call in PBX , you have A lot Options , like
Change your OCS normalization role to add more (9) , so when you call from MOC 012XXXXXXX it will reach medication 9012XXXXXX
And your add role in your PBX remove (9) and do it External call ,
By the way there are a lot Options ,, it’s up for your internal and external design
Wish you got the meaning ….
jeudi 29 octobre 2009 11:02@VoIPnorm: other than our MS contacts I'm not aware of any means to give feedback to Microsoft. Where'd I go about to find such groups?
Just last week we were pulling our hair out again with regards to normalization - it's all being done on the gateway but the PBX on the other end needs numbers in one format (private) when the call is internal, and another (international) for external and our gateway (Dialogic) only allows one format per trunk. It all would be so simple if we could do the kind of number manipulation on the Mediation server as you can do on a CallManager.
After many trials and errors we finally have something working in almost every configuration (the only exception being MOC -> PBX subscriber which has a CFWDAll to an external number.. there we get the main number displayed instead of the calling number) - but give me a CCM in between and I can give the Alcatel PBX the number in whatever format they need and we don't even need any hardware as we could go the SIP route that way.
The lack of flexibility means we have to stick with hardware gateways (we're hoping Dialogic will come back with an earlier fix that allowed to set the format on a route level rather than trunk level) even when SIP would work just fine.. just because we cannot get the numbers the way we need them.
vendredi 30 octobre 2009 02:00Hi Stephen,
Totally understand your frustration as it has been echoed by a number of Microsoft customers. Another option you may want to consider is there is a product called Smart SIP by Evangelyze http://www.evangelyze.net. This may or may not suit your requirements but I have heard of them doing something similar with this product. Mike Stacey who posted above would be a good contact for that product adn he will be able to give you a full product brief.
Send me an email at either the address on my blog or technet profile as I would like to know more about your issues and maybe I can help somewhat with contacts in your region.