Hey,

I get this error message when calling into an unassigned number which redirects to a response group:
------------------------------------------------------------------------------------------------------------ From user URI:
sip:onzlyncfe1.domain.co.nz@olympic.co.nz;gruu;opaque=srvr:Microsoft.Rtc.Applications.Acd:RS6nRGV9DlmpNsLtmz5qeQAA
To user URI:
0220198611;phone-context=DefaultProfile    
From user agent:
RTCC/4.0.0.0 Response_Group_Service Announcement_Service    
Diagnostic header:
26005; reason="The Response Group application was unable to transfer the call to the configured destination and no fallback exists." ------------------------------------------------------------------------------------------------------------

Interestingly "To user URI: 0220198611;phone-context=DefaultProfile" is the number off the caller not the destination. I wonder is this a bug? So is the response group trying to transfer to this number and failing because of course it doesnt exist?


As you can see the below the number I am calling is not 0220198611: 
------------------------------------------------------------------------------------------------------------ From phone number: 0220198611;phone-context=DefaultProfile
To phone number: +6493760053 From mediation server: onzlyncfe1.domain.co.nz To mediation server: From gateway: 192.168.100.70
To gateway:
Disconnected by: +6493760053 ------------------------------------------------------------------------------------------------------------

Does the calling party's number have to be normalised? If so how can I do this because the global normailisation rules dont seem to apply in this situation. These rules do work when when calling into a users DDI. 



Also to be clear....
+6493760053 is an unassigned number which is setup to redirect to a response group.

If I assign +6493760053 to a user then it works.
Additionally this works perfectly when the gateway sends the call to our legacy 2007r2 mediation server then on to Lync. If the gateway sends the call directly to the co-located Lync mediation server I get the error described.


I hope I make sense. If you are confused let me know :)

Help is appreciated.

Thanks, Andrew

Andrew.

Little confused here.  Are you trying to have an unassigned number in Lync transfer to a Lync Response Group?  From what I understand, when you do this it fails and cannot find the user (or response group).  But if you have the unassigned number transfer to a user it works. 

Did I understand you correctly?

Mark

Hey Mark,

 

Sorry for the confusion. I am trying to have an unassigned number transfer to a Lync response group but it fails. If I assign this unassigned number to a user it works fine.

 

Hope that helps :)

 

Thanks,

Andrew

Still struggling with this any ideas??

It seems the error maybe because unassigned numbers are not being normalised. Without normalisation the number does not match any destination.

How can I normalise all numbers even if they are not assigned a voice and dial plan policy like users are??

 

Thanks,
Andrew 

Hi ANdrew

Kindly advise how you transfered the unassigned numbers to a specific user, i used the below command but it failled, the message displayed but the call never routed:

 

New-CsAnnouncement -Parent service:ApplicationServer:LyncFE.squareone.local -Name "SQ unassigned number announcement" -TextToSpeechPrompt "You entered an invalid extinsion you will be forwarded to the operator" -Language "en-US" -TargetUri "sip:+96614650000@squareonemea.com;user=phone"

 

While +96614650000@squareonemea.com is the sip uri in my lync for the operator

 

could you advise what is my issue?

Do you have any update? I have same issue :(

Unfortunately my memory doesn't stretch back that far. Create a new post with a bit more detail and post back the link and I will see if I can help.

I have seen the same thing in my environment.  The Error is bogus.

What happens, is during the forwarding of the call from the original called unassigned number to the response group, the caller hangs-up, and creates these errors, even though nothing is wrong really.

You can verify by identifying the call on the PSTN gateway logs, and verify that the first BYE is coming from the gateway to Lync.