Ask a questionAsk a question
 

Proposed AnswerOperator Extension Problems

  • Wednesday, March 05, 2008 4:43 PMVictor Vale Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hi everyone;

     

    I can't seem to get the Operator extension in either the DialPlan or in an Auto Attendant to transfer an incomming call to my Operator extension.  I get the message "Sorry I was unable to transfer you to the operator".

     

    I will explain my current setup, which is a bit different from your standard setup.

     

    I have OCS 2007 implemented with Inbound/outbound calls as well as all the other advantages that OCS has to offer (IM, Presence etc).  I should note that there is no PBX system.  All numbers come in through a Digital ISDN 30 Channel PRI.

     

    I've recently added UC system to this setup.  OCS is currently set up as my UC IP Gateway, and I've enabled users for UC with 4 digit extension.  I've set up a quite complex AA system where by the caller navigates through different departments, and is able to either say the name of the person he wishes to contact or key in the 4 digit extension, and that rings the right person up.  Because I'm using OCS, the person gets an incomming call on Office Communicator or his/her configured end points.

     

    All that works fine.  But I'm trying to add an Operator to the AAs so if the caller presses 0 he/she would be transfered to a valid UC enabled user.  But that's were everything fails .

     

    All I can see in my Application log is in my UC Box:

     

    Event ID: 1136

    An error occurred while transferring the call to the phone number "1001". The call ID is: "f651205e-9d33-498c-abbf-7c5fe031e3c4".

     

    Any ideas on how to go about solving this?

    Or has anybody got a similar scenario set up and working?

     

    Thanks in advance.

All Replies

  • Sunday, April 06, 2008 5:10 PMScott Ellis Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    I'm in the same situation. Have no PBX system, PSTN lines are directly connected to Audiocodes MP-118 media gateway -> microsoft mediation server -> ocs 2007 and exchange 2007 Unified Messaging.

     

    I have setup a valid UM extension (3912) as the Operator extension in the dial plan.

     

    When the caller press 0, I get "sorry I was unable to transfer to the operator". I can see the error in the event log as well.

     

    Event ID: 1136

    An error occurred while transferring the call to the phone number "3912".

     

    If the caller dials 3912 directly during the Auto Attendant greetings , it works fine but pressing 0 to transfer the call to 3912 is not working.

     

    Please help!

     

    Thank you.

  • Thursday, April 17, 2008 4:06 PMVictor Vale Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

     

    Has anybody found an answer to this?

     

    Help!

     

    Thanks.

  • Wednesday, April 23, 2008 9:06 AMRientsNL Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

     

    Hi,

     

    it seems to me that you guys miss a call translaton from a four digit extension number to ocs format.

    Exchange does not use a "+" so communicator needs to put it in front of the operator number by itself.

     

     

    Use this normalization rule in your location profile:

    Phone pat. reg ex: ^(\d{4})$

    Translation patt reg ex: +$1

     

     

    This sould solve your problem...

     

    Good Luck Ruben

  • Wednesday, April 23, 2008 10:25 PMScott Ellis Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    #1: Add a Normalization Rule to convert 4 digit extension to E.164 format

     

    Expression: ^(\d{4})$

    Translation: +$1

     

    #2: Update User’s Line URI to the Extension in E.164 format

     

    E.g. tel:+3912

     

    #3: Wait for about 10 minutes for AD/OCS to update

     

    #4: http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&displaylang=en is a good tool that would allow testing all the routes

     

  • Wednesday, July 09, 2008 9:24 PMewright19 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    I have OCS 2007 Std installed and configured

    I have a Mediation Server, Exchange Server, Hub Transport, Client Access, Mailbox, Domain Controller, and UM Server Installed, and an AudioCodes Gateway connected to the PSTN.

    My Users are all UM Enabled and have no trouble connecting to OVA and OVA's features.

    I have an Auto Attendant configured in UM enabled with extension 2916.

    I have an Operator Extension inside the Auto Attendant configured with 2919 which is the same as one of my UM Enabled Users.

    I have the same Operator Extension configured in the UM Dial Plan.

    In the UM Dial plan I have a rule

     

    Name: local

    Number Mask: 2xxx

    Dialed Number: +2xxx

     

    I have the Normalization Rules configured in OCS:  Including the one posted above: 

    Expression: ^(\d{4})$

    Translation: +$1

     

    All my UM Enabled User's are also OCS Enabled users.

    From an external PSTN line, when I connect to the AutoAttendant (x2916) and say "Operator" the System says "Calling the Operator.  Sorry, I was unable to transfer you to the Operator. Welcome to the Microsoft Auto Attendant...."

     

    The UM Event Viewer shows:

     

    An error occurred while transferring the call to the phone number "2919". The call ID is: "35670f62-54c5-43eb-9b80-2a217803612e".

    "

    Session Initiation Protocol (SIP) REFER command that is being issued by the Unified Messaging server cannot be accepted by a SIP peer (IP/VoIP gateway or IP/PBX).

     

    The Mediation Server receives sip:2919 as the requested input and fails as it doesn't know where to send it. 

     

    TL_ERROR (TF_PROTOCOL) MediationServer (ProxyCall.ProxyParticipateComplete:343.idx(1503))       [3]0
    720.0640::07/09/2008-21:19:36.117.00000a20
        ( 029EB1EC )$$START-MEDIATIONSERVER
    MediationCall: f5d771405fc04339bba10d64fc1a59a3
    CallId: 82ac683e-e000-4c7e-8082-42fe712cf723
    From: sip:1024;phone-context=unknown@unifiedcommunications.com;user=phone
    To: sip:2919;phone-context=ocsgateway64.unifiedcommunications.com@unifiedcommunications.
    com;user=phone
    Direction: Inbound
    Start-Line: FailureResponseException: ResponseCode=400 ResponseText=The specified phone profile was
    not found.
    DiagnosticInformation=ErrorCode=14005,Source=ocsstd1.unifiedcommunications.com,Reason=Could no
    t find profile in internal lookup
    Microsoft.Rtc.Signaling.DiagnosticHeader

    Microsoft.Rtc.Signaling.FailureResponseException: The requested operation failed.
       at Microsoft.Rtc.Signaling.SipAsyncResult.ThrowIfFailed()
       at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult asyncResult)
       at Microsoft.Rtc.Signaling.Helper.EndAsyncOperation[T](Object owner, IAsyncResult asyncResult, St
    ring operationId)
       at Microsoft.Rtc.Signaling.SignalingSession.EndEnter(SipInviteAsyncResultWrapper asyncWrapper)
       at Microsoft.Rtc.Signaling.SignalingSession.EndParticipate(IAsyncResult asyncResult)
       at Microsoft.RTC.MediationServerCore.ProxyCall.ProxyParticipateComplete(IAsyncResult ar)

    $$END-MEDIATIONSERVER

     

    Can someone help me resolve this problem? It looks as if there needs to be a local profile for the UM AA.??? How does that get created?

     

    Many Thanks in Advance. 

     

     

  • Tuesday, April 21, 2009 10:02 AMsteventhong Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Proposed Answer
    I'm also facing the similar problem. After hours and hours of troubleshooting and looking at logs of a working server vs my server that is failing to route, here's the culprit that is causing the error: 

    FROM: <sip:anonymous@domain.com;user=phone>;epid=C7F3054576;tag=2439caf62
    TO: <sip:443;phone-context=dialplan.domain.com@10.0.0.200;user=phone>;tag=223A1EE3F789C9C5A12B24622C75E074
    CSEQ: 121 INVITE
    CALL-ID: 600c5b6e-20b7-4ded-83a5-2f15aa1c5f95
    VIA: SIP/2.0/TLS 10.0.0.49:51807;branch=z9hG4bKff9b4360;ms-received-port=51807;ms-received-cid=283500
    CONTENT-LENGTH: 0
    ms-diagnostics: 1022;reason="Cannot process routing destination";source="OCSFrontEnd.domain.com";Destination="sip:443;phone-context=dialplan.domain.com@10.0.0.200;user=phone" 

    From the above, the phone-context is passed on as 'dialplan.domain.com@10.0.0.200 (10.0.0.200 = Front end server IP address). However, a working phone-context should be showing as 'dialplan.domain.com@ForestFQDN'.

    I have no idea why it's returning the phone-context this way because I've compared it on another similar implementation I've done recently, the phone-context returned correctly as 'dialplan.domain.com@forestFQDN'.

    Any help and advice is greatly appreciated!
    • Proposed As Answer byRob Husted Friday, July 17, 2009 5:38 PM
    •  
  • Friday, July 17, 2009 6:01 PMRob Husted Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sorry, I clicked the wrong button, did not mean to propose the above comment as an answer.

    We were struggling with getting the 0-out to work on our Exchange UM today.  We have our OCS setup in several ways.  We have Enterprise voice with a mediaton server integrated with Avaya Communicaiton Manager.  We also have Exchange directly integrated with Avaya and Cisco PBXs.  0-out worked fine for users on Avaya or Cisco phones.

    Users that were on Microsoft EV with Exchange UM as their voicemail had a 0-out location setup to go to our main receptionist residing on our Avaya PBX which is a simple 4 digit extension.  But when we hit 0, Exhcnage came back with "Sorry, I was unable to transfer you to the Operator" and would proceed to take a message.

    Tracing the issue on OCS, we found that the mediation server was choaking on the 4 digit extension.  It couldn't normalize it to E.164.  I'm not sure why as our normalization rules in OCS are working fine and we can call the receptionist without problem.

    I resolved the issue by creating a Dialing Rule Group in the Exchange Dialplan for OCS for the operator that converted the 4 digit extension to E.164 format and then added it into the allowed in-country/region rule groups from dial plan on the Dialing Restrictions tab.  This is converting the number correctly and OCS now knows what to do with the number.  The call is sent to our IP gateway where the manipulation rules are correcting the number and sending it to our PBX.

    I Hope this helps someone.
  • Monday, October 12, 2009 7:06 PMjocellus222 Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Need to revive this thread.  UM SIP Dial Plan, OCS, Cisco and Avaya environments.

    I am able to get the personal zero out to work by creating the dialing rule group, but am not able to get the zero out from the main menu to work.  The main menu zero out is reached by clicking # to contact someone and then press 0 for operator.  It would make my life a whole lot easier if the call to the dial plan operator was treated the same as the personal operator.

    I see the call to the operator come to OCS environment as refer and the normalization rules aren't being applied until it does the reverse number lookup.  At that point I get User not found.  The call is not found in the gateway traces. I was hoping it would at least reach there, because I can create a translation rule there to handle the non E164 number.  I've even created a route for the non E164 number and an explicit normalization rule for the number.  

    Has anyone had luck with the main menu zero out on a SIP dial plan going through the OCS Infrastructure?  If so please share :) I think this is a bug.

    Thanks,