Jump to content

Jan Boguslawski

  • Posts

  • Joined

  • Last visited

About Jan Boguslawski

  • Birthday 03/12/1976

Contact Methods

  • AIM
  • MSN
  • ICQ
  • Yahoo

Profile Information

  • Gender
  • Location
    Berlin, Germany
  • Interests
    pbxnsip<br />snom<br />Microsoft Exchange 2007<br />Unified Messaging<br />Microsoft Office Communications Server 2007<br />Microsoft Office Communications Server 2007 R2<br />Unified Communications Collaboration and Control

Jan Boguslawski's Achievements


Newbie (1/14)



  1. Hi @all please imagine a situation were user's work sometime's from home and like to use their own fixed or mobile phone to do the office work. This user's also like to use remotly the TAPI or Remote Call initiation via Web-Links like described in the wiki topic Click to Dial. Should this users be configured with Hot Desking to their home / mobile phone numbers or do we need to forward all calls to the number preferred by the home office worker? What might be the best way to provide the users a self maintenance service for changing their account configuration for this home office situation and back to standard office use at any time? In both cases: TAPI and Click2Dial-Web-Links is it simply a call (sip-invite) made by the system to the user? Thanks, Jan
  2. Hi I agree with Alex. It seems since 3.1.1 some major changes had been implemented. This "country code" + ANI + "global number rewrite" features seems to complicate things (just my point of view,as I didnt understand it atm.) But what is very strange to me, it becomes impossible to recreate the "good old" behavior from older versions. An example: If you take a look at the wikipage for OCS the trunk settings for: With this settings it was possible to pass the OCS-Tel-URI via pbxnsip to another trunk for example AudioCodes Mediant 1000 VoiP gateway. So in PSTN your DID arrived at the callee. But now the number from the setting "Assume that call comes from user " is passed for every OCS user or the OCS Conference and Exchange Play on Phone, etc. Since 3.1.1 this seems not to work, or I simply dont understand how to recreate this behavior with the new features... Please advise! Thanks. Regards, Jan
  3. Hello Kaj, Hello pbxnsip, I guess we can find the solution for this challenge in this AudioCodes Document about: Configuring AudioCodes Gateways to Operate in TLS Transport Mode with Microsoft™ Mediation Server In step II it tells about the Mediations Server Preparation, and a hotfix for this TLS Setup. (it is not MTLS like normal between all OCS Roles) My verdict is, in your case: 1. OCS is doing an outbound call and presenting its certificate. Pbxnsip is simply accepting it. Does it make an crl (Certificate Revocation List) check to the rootCA? I guess not. 2. But OCS is not accepting the certificate presented by pbxnsip. Maybe the hotfix will ease this. Please give the AudioCodes document a try. btw: I am sure you dont need to buy a commercial certificate! If it does not work with the windows CA, it will never work with a payed one! Lets save the money Best regards, Jan
  4. Hello Tim, please carefully check / filter the OCS Event log in the event viewer for Event-ID 21034 You should find a lot of entries telling: I am sure the BPA report has had related warnings on that events. Please tell me about your findings. Regarding your other topics: yes all that you asked for is possible, but... It is a long story, with pros and cons and a lot of different approaches... I explained one here in another post. Please excuse that I can't go into all details here, it would be to much to write... Are you sure, you are aware of the headaches that Microsoft Office Communicator Phone Experience Device (Yes it is the official product name short term MS MOCPED )phones can cause to your colleagues and especially to you or Eric??? ;) Please be careful with that! If you think this is a must have, I strongly recommend you to evaluate and test a lot, also with your team! Regards, Jan
  5. Hi @all Unified Communications friends I like to spotlight you on an issue with OCS R1 and R2 regarding a call drop after exact 30 seconds. This happens in some integration scenarios with IP-pbx, some VoIP-Gateways and maybe also with VoIP-providers. It seems to be related how OCS components / roles check RTP streams on silence (both directions). One example of that can be found here with Cisco Unity. In pbxnsip you can face this problem e.g. when you put an external caller on hold in Office Communicator or R2-Attendant Console. Typically Mediation Server will send a bye after the 30 sek. Drago (in the forum discussion about the Unity issue) has an interesting explanation: Snom with their native OCS Edition phones also faced that problem in a similar way. But they have find a workaround J They are sending short none audible audio during the 30s. Maybe this workaround can be featured at an special pbxnsip trunksetting too? Or maybe a OCS native solution, which e.g. is done by AudioCodes Gateway's for Microsoft UC (sorry I dont know the details atm. but I can provide ACsyslog traces, where you might see what is happening if you put someone onhold in a direct OCS Mediation <-> AC Gateway scenario. I think they dont send none audible audio. Regards, Jan
  6. Hi Tim, you are welcome! Thanks for your compliment. OCS / Exchange / VoIP / pbxnsip / snom / AD / DNS / ISA etc. are just my "bread-and-butter" Please download, install and run OCS Best Practice Analyzer. from MS download center. When you run it the first time, please make sure you run it as Administrator and that you check for updates (inside the tool) before your first analyze run. The update step will download the latest info's about OCS R2 into the BPA. You run R2, don't you? Beside a lot of warnings and errors, the report results will warn you about telephone numbers that could not be "normalized". The Report will guide you to a file which contains all the "wrong" formatted numbers in your Active Directory. I guess you will see here all of the bussiness numbers starting with (301)... and the Mobile Numbers. Please update me about the results. Regards, Jan
  7. Hi DWAyotte, you are welcome. Sounds strange for me too. Please let's clarify the situation you are facing: You start a call via a hardphone (sip-phone registered at pbxnsip???, which model & brand?) and the callee! picks up? (what kind of callee -pstn, pbxnsip, ocs-user?) In that case your phone continous to ring? And the same happens when you start the call via communicator? Please try to explain your cases more detailed and describe who is calling who and with what kind of device/software! Regards, Jan
  8. Hi Tim, please add a leading plus in front of you number at the static registration in pbxnsip and at the tel URI at the OCS user account Enterprise Voice settings. Should look like: 1. sip:+2007@ocsmediationserver.domain.xx;transport=tcp 2. tel:+2007 OCS Mediation Server needs the E.164 format with the leading + As my example shows, you dont need to provide a real and complete international DID number with national digits etc. , but you need the plus! Additionally please start logging at the mediation server before testing and Analyze the Log in OCS Snooper Tool! Regards, Jan
  9. Hi Eric, I think you can easily solve this problem using e.g. 9999* instead of 7* The 7* is just an example and my 9999* is also just an example. This is how we use it. No conflicts so far (since 2006 with MS Exchange Unified Messaging beta3 Ohh How time flies!). btw: dont forget to assign the exchange trunk another preference in your dialplan. best regards, Jan
  10. Hi Michael their are no silly questions, only silly answers What about an Snom 820. http://www.snom.com/fileadmin/user_upload/...820_frontal.jpg It's extremly flat and when you remove the food it would fit perfectly at walls, I guess. The handset would still be secured by a small pin. btw: I like my 820 on my desk best regards, Jan
  11. Hi deva, from what you described, my first impression is: 1. maybe a little misconfiguration in your setup. Did it ever worked the way you expect it? 2. sounds like a wrong or no diversion header info, so Exchange would not be able to recognise this is a redirected call and simply receives a call. Thats why it ask's for the PIN. Did it also ask for A's extension ??? Please describe your configuration more detailed! Maybe compare it carefully with the wiki page: http://wiki.pbxnsip.com/index.php/Microsoft_Exchange Additionally: enable Unified Messaging Diagnostic Logging at Exchange UM via Powershell: http://technet.microsoft.com/en-us/library/bb430783.aspx If I remember correctly you can do e.g. a one-liner like this: get-eventloglevel *UM* | set-eventloglevel -level Expert To change all UM related loggings. Please give it a try It's like voodoo Or try this one get-service | restart-service -force Best regards, Jan
  12. Hi Dave, No problems so far, we are on Rollup 7 now. But I share your precaution, everytime a new Rollup is released When will this product be RTM ? Best regards, Jan
  13. Hi Quentin, if you have OCS R2, why you dont try using the R2 Response Group Service? You can easily configure Workflows, Agents, Huntgroups - working our's, holidays etc. This will also respects OCS presence state and offers you a lot of basic and advanced ACD options. In your described case, user can redirect the second call in a "please wait a moment - I am in a call workflow". Configuration of this workflows can be very granular, but you will easily understand what is configured. You described so OCS R2 Attendant Console might be the better client for this user, instead of Office Communicator. Please give both option's a try Best regards, Jan
  14. Hi DWAyotte, please carefully compare your setup with the OCS pbxnsip wiki page: http://wiki.pbxnsip.com/index.php/Office_C...ications_Server ! Trunk call: Could not identify user typically means you missed this part of the article: I am looking forward, to your feedback! Good Luck! Best regards, Jan
  15. Hello Louis, are you still facing this problem? Or did you found a solution. I am not sure, but I guess I have seen something similiar. If possible, please update us with your status! Best regards, Jan
  • Create New...