locked
Auto Attendant Not Connecting RRS feed

  • Question

  • I ran through all the deployment steps to integrate Exchang<->OCS.  Voice mail works fine, subscriber access works fine internally and externally.  All calls connect perfectly, except I cannot connect to the Auto Attendant.

    I must admit that the whole idea of an extension, its length and the phone number format is not explained very well Exchange vs. OCS.  I used the OCS format for the Subscriber Access even though I set the extension numbers to be 4 digits long.  I added all 3 numbers (full OCS nubmer, 3 digit extension, sip id) to the auto attendant:
    +18325552600, 2600, autoattendant@domain.com

    I tried it with each one individually, and then also with all 3 of them at the same time.

    Communicator shows the Auto Attendant by name, the Auto Attendant name entered with the OCSumUtil.exe created that contact id.  I stored it in the same configuration container:
    CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=domain,DC=com

    I dialed the extension internally and externally and the call will not go through.

    I have a response group setup on another extension that I wanted to transfer to the auto attendant as an option or after a specified length of time on hold.

    I think everything with OCS and Exchange is working except the Auto Attendant.

    There is no PBX.  Just using OCS and Exchange for Telephony.  Mediat Gateway is an Audiocodes Mediant 1000 - although I don't think the Media gateway has anything to do with this problem.  The only UM IP Gateway is the OCS Pool.

    -Barry
    Sunday, May 10, 2009 3:49 AM

Answers

  • Success!

    The contact sip uri & the Auto Attendant chosen when the contact id is created are all important to be correct.

    I cannot say what exactly went wrong the first time I created the contact using the OCSumUtil, but I noticed that the name of the Auto Attendant that was used during the call trace was not the same name I gave the Auto Attendant when I created it in Exchange.

    What I think happened has to do with how the OCSumUtil/tool works.  When you create a contact using the utility it offers you 2 types of contacts to create, either a Subscriber Access Contact OR an AutoAttendant Contact.  When you choose the Auto Attendant Contact, it enables a drop-down list to choose which auto attendant this contact id will be created for.

    You need to be careful when you are doing all this because if you leave the tool running it will contain data FROM THE LAST TIME YOU LOADED DATA FOR YOUR FOREST/DOMAIN.  If you change the name of the Auto Attendant(s) after you loaded the forest/domain information, you need to ReLoad the data before you create a Contact Id using the tool.  If you don't it will still have the old Auto Attendant Names to choose and you may be confused as I was by for example a generic name for Auto Attendant.  When I created the First Auto Attendant I gave it the name "Auto Attendant".  So when I saw that down at the bottom of the dialog I just thought it was saying it was a contact for the Auto Attendant and it took me quite a long time to figure this out.

    Now, this did not happen as simply as I have described here.  I deleted and recreated that contact many times and often I did reload the data, but I apparently was changing things here and there so many times that I was not syncronizing the changes to make sure everything was all together correct.

    So, the moral of the story is to be careful about chosing your names and keeping them consistent when entering the name data in other places, and make sure you reload the forest/domain data in the OCS/UM tool before you create a contact Id with that tool.

    I hope my effort will provide another user some assistance if they have similar problems.

    Thanks a lot Drago for your assistance.  Your suggestions kept me thinking about what the possible issues were!

    -Barry
    • Proposed as answer by Drago Totev Thursday, May 14, 2009 11:31 AM
    • Marked as answer by Barry Adkins Thursday, May 14, 2009 4:04 PM
    • Edited by Barry Adkins Thursday, May 14, 2009 4:07 PM
    Thursday, May 14, 2009 7:18 AM

All replies

  • First, dial +18325552600 from MOC and see if connects at all. If yes, create normalization rile to convert your 3 (or 4) digit number to +18325552600 (E.164 format). I am using "*99" to translate to the E.164 number of AA and it is all good. In any case, you must present "+" in front of the number or it will not work. So, your 2600 must be normalized to +2600... Still the best way would be to use: " if the number is 2600 translate to +18325552600".

    Drago

    Sunday, May 10, 2009 9:58 PM
  • Call does not connect from MOC whether I dial a 4 digit extension or the whole number (normalization already translates 2600).  I already have a normalization rule.  2600 is just another extension, so it gets normalized to +18325552600 just like any other extension it is evident on MOC where it shows the translation on the fly like any other normalization.  I also tried dialing using its sip address (sip: autoattendant@domain.com).  MOC reports that sip address is "offline," but sip: subscriberaccess@domain.com also shows presence as offline, yet it dials and connects just fine.

    I have not done a log trace, that's the next step assuming it is properly configured.  Strange that the subscriber access extension works, but the auto attendant does not.

    At the moment since we have a Response Group working it is not super critical for this to work, accept I wanted callers to be able to connect to the auto attendant so they could leave a message if the Response Group did not take the call quickly enough.

    -Barry
    Monday, May 11, 2009 2:14 AM
  • Just thought about something... Check your UM server's Windows Events log. If you see an error (don't remember exactly the Err. number) but will be with source "MSExchange Speech Engine", your problem is the the Front End server's certificate. By default, when one use the Certificate wizard, a SAN for sip.domain. com is inserted... This causes UM to fail. Re-issue the Edge Server certificate and make you have a Common Name only, not SAN. Let us know.

    Drago

    *** I'm sorry. I should have said "Re-issue the Front End (OCS) certificate...", not Edge...

    Monday, May 11, 2009 2:30 AM
  • When I try a call to the Auto Attendant, I get no event logged at all on the UM Server.  That makes me suspicious the call is not even getting to the UM server.

    I still need to do a call trace on the OCS side.  I can't do that until Wednesday.

    -Barry
    Monday, May 11, 2009 4:45 PM
  • Following are from a trace log of the call to the Auto Attendant.  I can provide other portions if needed.  I've tried to filter out the important information.

    NOTICE that is knows it is trying to reach the Auto Attendant, and then at the bottom of this it says reason="The application specified an invalid request-uri"

    How do I figure out which "request-uri" it thinks is invalid? AND who thinks it is in valid, OCS or Exchange?  I tend to think it is OCS, because no event gets logged in the Appliation log on the Exchange UM Server.........   Trace Log data follows.....:::

    TL_INFO(TF_PROTOCOL) [3]05A8.0FC8::05/13/2009-06:37:53.990.00061ba1 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 0000CD77
    Direction: outgoing;source="local"
    Peer: 111.111.111.123:50106
    Message-Type: response
    Start-Line: SIP/2.0 101 Diagnostics
    From
    : "Barry D. Adkins"<sip:Barry.Adkins@domain-number2.com>;tag=b2a1c4d382;epid=41c8c59cfd
    To: <sip:+18325552600@domain-number2.com;user=phone>
    CSeq: 1 INVITE
    Call-ID: 70d3282fe8f34e3da7e70b21de0ab67b
    Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF4F2AAAC3989CD1289D41B5FD88AF5251", srand="D53DB88B", snum="45", opaque="37D934D9", qop="auth", targetname="sip/OCSfrontEndServer.domain.com", realm="SIP Communications Service"
    Content-Length: 0
    Via: SIP/2.0/TLS 111.111.111.123:50106;ms-received-port=50106;ms-received-cid=32F00
    ms-diagnostics: 15009;reason="Routing to UM for Auto Attendant";source="OCSfrontEndServer.domain.com";dialplan="HOU.domain.com";umserver="exchUMserver.domain.com";aaname="HOU Auto Attendant";appName="ExumRouting"
    Server: ExumRouting/3.5.0.0
    Message-Body:


    Wednesday, May 13, 2009 7:14 AM
  • The following somehow did not show up in the previous post - it is a 2nd trace log snippet:

    TL_INFO(TF_PROTOCOL) [3]05A8.0FC8::05/13/2009-06:37:53.990.00061dad (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 0000CD79
    Direction: outgoing;source="local"
    Peer: 111.111.111.123:50106
    Message-Type: response
    Start-Line: SIP/2.0 400 Bad request
    From
    : "Barry D. Adkins"<sip:Barry.Adkins@domain-number2.com>;tag=b2a1c4d382;epid=41c8c59cfd
    To: <sip:+18325552600@domain-number2.com;user=phone>;tag=68814A57A75F33BFE94CCACE957CB9EE
    CSeq: 1 INVITE
    Call-ID: 70d3282fe8f34e3da7e70b21de0ab67b
    Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFFC4A676FAF390AF7670F3CDF4AE658A40", srand="5C816237", snum="46", opaque="37D934D9", qop="auth", targetname="sip/OCSfrontEndServer.domain.com", realm="SIP Communications Service"
    Via: SIP/2.0/TLS 111.111.111.123:50106;ms-received-port=50106;ms-received-cid=32F00
    ms-diagnostics: 1;reason="Service Unavailable";source="OCSfrontEndServer.com";AppUri="http://www.microsoft.com/LCS/ApiModule";reason="The application specified an invalid request-uri"
    Content-Length: 0
    Message-Body:


    Any help will be appreciated!!!!!!!!!

    -Barry

    Wednesday, May 13, 2009 7:20 AM
  • Barry,

    Here is the beginning of the SIP trace when I dial AA. It does not look like OCS is sending it to the right place. Install Wereshark on your UM server and trace there as well... I think you have configuration issues since OCS is not aware of the FQDN of your UM server to start with...

    TL_INFO(TF_PROTOCOL) [3]1534.03B4::05/13/2009-11:06:53.264.001a8d48 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 0049322A
    Direction: outgoing
    Peer: um.gmc.cc.ga.us:5061
    Message-Type: request
    Start-Line: INVITE sip:Directory_Assistance_AA.Directory_Assistance@um.gmc.cc.ga.us:5061;transport=tls;maddr=um.gmc.cc.ga.us SIP/2.0
    From: "Drago Totev"<sip:user@gmc.cc.ga.us>;tag=cbbf3b1107;epid=cbdda97bd0
    To: <sip:+14783874834@gmc.cc.ga.us;user=phone>
    CSeq: 1 INVITE
    Call-ID: 533d97aa298d978ef4f1f4fe330574f4
    ms-user-data: ms-publiccloud=true;ms-federation=true
    Record-Route: <sip:mil.gmc.cc.ga.us:5061;transport=tls;ms-fe=milfe01.gmc.cc.ga.us;opaque=state:T:F;lr>;tag=01E327D3F48B517D5BD4872CEA3D8E4E
    Via: SIP/2.0/TLS 10.0.40.22:2753;branch=z9hG4bK704D0E9C.E26AF88CA1B2619D;branched=TRUE
    Max-Forwards: 68
    Content-Length: 3727
    Via: SIP/2.0/TLS 10.8.4.12:59617;ms-received-port=59617;ms-received-cid=37EC00
    P-Asserted-Identity: "Drago Totev"<sip:user@gmc.cc.ga.us>,<tel:+14783874390>
    Contact: <sip:user@gmc.cc.ga.us;opaque=user:epid:XwR8n50UIlCYywbLA7aYiQAA;gruu>
    User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)
    Ms-Conversation-ID: AcnTuuqYr83pSXqxfvv77x5h7Mi83Q==
    Supported: timer
    Supported: histinfo
    Supported: ms-safe-transfer
    Supported: ms-sender
    Supported: ms-early-media
    Supported: Replaces
    Supported: 100rel
    ms-keep-alive: UAC;hop-hop=yes
    Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
    Supported: ms-conf-invite
    Content-Type: multipart/alternative;boundary="97e2de1cf838806f1e820128f8837e1b"
    Ms-Application-Aor: <sip:Directory_Assistance_AA.Directory_Assistance.gmc.cc.ga.us@gmc.cc.ga.us>
    Ms-Mras-Address: <sip:sipint.gmc.cc.ga.us@gmc.cc.ga.us;gruu;opaque=srvr:MRAS:a-iER0mgnECvwkZdpgN02gAA>

    Drago
    Wednesday, May 13, 2009 11:28 AM
  • This is how it starts, and it is EXACTLY like how the subscriber access call starts, and that call completes just fine to the UM server.  I don't understand what you mean that "OCS is not aware of the FQDN of your UM server to start with" when it is sending calls to voice mail, allowing me to dial and connect to the voice mail subscriber access, etc.  I will try to trace on the UM server with the program you mentioned...:::


    TL_INFO(TF_PROTOCOL) [2]05A8.09F0::05/13/2009-06:37:53.944.0005ba1d (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
    Instance-Id: 0000CD6B
    Direction: incoming
    Peer: 111.111.111.123:50106
    Message-Type: request
    Start-Line: INVITE sip:+18325552600@domain-number2.com;user=phone SIP/2.0
    From
    : <sip:Barry.Adkins@domain-number2.com>;tag=b2a1c4d382;epid=41c8c59cfd
    To: <sip:+18324942600@domain-number2.com;user=phone>
    CSeq: 1 INVITE
    Call-ID: 70d3282fe8f34e3da7e70b21de0ab67b
    Via: SIP/2.0/TLS 131.192.177.123:50106
    Max-Forwards: 70
    Contact: <sip:Barry.Adkins@domain-number2.com;opaque=user:epid:_eC8Pr4aXF2zsurDBqG66QAA;gruu>
    User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)
    Ms-Conversation-ID: AcnTlVqcQ863gMIXTfWqOY47oT6Ntg==
    Supported: timer
    Supported: histinfo
    Supported: ms-safe-transfer
    Supported: ms-sender
    Supported: ms-early-media
    Supported: Replaces
    Supported: 100rel
    ms-keep-alive: UAC;hop-hop=yes
    Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
    P-Preferred-Identity: <sip:Barry.Adkins@domain-number2.com>, <tel:+18324942504>
    Supported: ms-conf-invite
    Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="37D934D9", targetname="sip/OCSfrontEndServer.domain.com", crand="16a4640c", cnum="24", response="602306092a864886f71201020201011100ffffffff650335b10aefc52769a827c19cff75ea"
    Content-Type: multipart/alternative;boundary="----=_NextPart_000_0107_01C9D36B.71D585B0"
    Content-Length: 2820
    Message-Body: ------=_NextPart_000_0107_01C9D36B.71D585B0

    -Barry

    Wednesday, May 13, 2009 2:22 PM
  • Well I can tell from the packet analyzer that when I call the subscriber access number, the UM server gets a flood of packets which are TLS, SIP, etc.

    When I call the Auto Attendant, NO Packets at all.  I filtered to only look for packets from the OCS server.  Since that server is the mailbox server it gets tons of packets.

    Now I've got to figure out why the OCS server does not find its way to the UM server for the Auto Attendant, but it does for voicemail and subscriber access.

    I am very puzzled.

    -Barry
    Wednesday, May 13, 2009 3:08 PM
  • You spent too much time on this already... (smile). Why not delete this AA and re-create it again?

    Drago
    Wednesday, May 13, 2009 4:25 PM
  • No harm in trying, but since the call is not getting to the UM server I don't see how it will fix the issue, but then sometimes with computers there is no logical explanation why something so benign like "starting over" works even when you do the same thing.

    -Barry
    Wednesday, May 13, 2009 9:02 PM
  • Deleted Auto Attendant Contact, deleted the Auto Attendant, Added a new Auto Attendant, created new Contact using the OCSUM tool... same problem as before.

    I also deleted the subscriber access contact object, then recreated it... It stopped working, but it was because I changed the sip uri to a different name.  I changed that back and it started working again.

    That leads me to believe the problem has something to do with how the contact object is created, what it is named, and perhaps where it is saved makes a difference.

    Any other suggestions would be tremendous!

    -Barry
    Thursday, May 14, 2009 4:14 AM
  • I have deleted the AA and recreated it several times.  This last time I did not alter the name that the OCSumTool wanted to use for the sip uri.

    Before the Subscriber Access URI was always reported as "offline" and the AutoAttendant was reported as "Presence Unknown".

    Now both are reported as "Offline".  Which only makes me feel better that the non-working contact id at least reports the same as the one that works.


    Yet, the Auto Attendant still does not work.  My next step is to try using a different extension number for the Auto Attendant and see if that makes any difference.

    -Barry
    Thursday, May 14, 2009 5:57 AM
  • Success!

    The contact sip uri & the Auto Attendant chosen when the contact id is created are all important to be correct.

    I cannot say what exactly went wrong the first time I created the contact using the OCSumUtil, but I noticed that the name of the Auto Attendant that was used during the call trace was not the same name I gave the Auto Attendant when I created it in Exchange.

    What I think happened has to do with how the OCSumUtil/tool works.  When you create a contact using the utility it offers you 2 types of contacts to create, either a Subscriber Access Contact OR an AutoAttendant Contact.  When you choose the Auto Attendant Contact, it enables a drop-down list to choose which auto attendant this contact id will be created for.

    You need to be careful when you are doing all this because if you leave the tool running it will contain data FROM THE LAST TIME YOU LOADED DATA FOR YOUR FOREST/DOMAIN.  If you change the name of the Auto Attendant(s) after you loaded the forest/domain information, you need to ReLoad the data before you create a Contact Id using the tool.  If you don't it will still have the old Auto Attendant Names to choose and you may be confused as I was by for example a generic name for Auto Attendant.  When I created the First Auto Attendant I gave it the name "Auto Attendant".  So when I saw that down at the bottom of the dialog I just thought it was saying it was a contact for the Auto Attendant and it took me quite a long time to figure this out.

    Now, this did not happen as simply as I have described here.  I deleted and recreated that contact many times and often I did reload the data, but I apparently was changing things here and there so many times that I was not syncronizing the changes to make sure everything was all together correct.

    So, the moral of the story is to be careful about chosing your names and keeping them consistent when entering the name data in other places, and make sure you reload the forest/domain data in the OCS/UM tool before you create a contact Id with that tool.

    I hope my effort will provide another user some assistance if they have similar problems.

    Thanks a lot Drago for your assistance.  Your suggestions kept me thinking about what the possible issues were!

    -Barry
    • Proposed as answer by Drago Totev Thursday, May 14, 2009 11:31 AM
    • Marked as answer by Barry Adkins Thursday, May 14, 2009 4:04 PM
    • Edited by Barry Adkins Thursday, May 14, 2009 4:07 PM
    Thursday, May 14, 2009 7:18 AM
  • If we were getting paid for all that time spent chasing out tails... Glad you got it, buddy!

    Drago
    Thursday, May 14, 2009 11:31 AM