locked
Unassigned number calling from pstn is not working. RRS feed

  • Question

  • When calling from the pstn to an unassigned number in a configured unassigned number range, the logs show that instead of hitting the configured unassigned number announcement service, the call routes back to the gateway. This causes the call to bounce back and forth between lync and the gateway. When calling from a lync client to such a number the announcement service works as it should. I am able to call assigned numbers correctly.

    Any ideas?

    Monday, March 25, 2013 6:13 PM

Answers

  • This issue was finally solved by the July 2013 cumulative updates. Thank you for all your help along the way.
    Thursday, July 18, 2013 4:32 PM

All replies

  • What gateway are you using ?

    I will look at the transformation table in your gateway ? Do you have ;ext=xxx in transformation ?

    Tuesday, March 26, 2013 2:07 AM
  • The gateway is an Asterisk pbx. The calls route and connect correctly to every assigned number regardless if it's an exchange UM AA, a user, a workflow or whatnot. The only case where the call routes back to the gateway is when calling an unassigned number, and as stated the range is configured.

    In the unassigned number configuration, the range is configured for the entire range starting from +882990110850000 ending to +882990110859999 and should connect to an exchange AA at +882990110859999 (this works when calling from a lync client as I stated).

    The Asterisk routes all calls to ^\\+?(88299011085XXXX)$ (I marked this as pseudo regex for your convenience) $1 to the trunk connecting to Lync 2013 and the dial plan has normalization rules for ^(88299011085\d{4})$ +$1 and ^(\+88299011085\d{4})$ $1 marked as internal extensions. I also tried modifying the asterisk routes to include or add the + sign in the passed DID to see if that would affect the call routing but it proved meaningless.

    I'm not sure what transformation you mean where an ;ext=xxxx clause should/shouldn't be present.


    Tuesday, March 26, 2013 10:15 AM
  • If you are referring as to wether user extensions are used, that is not the case. Every user has their own personal DID and the auto-attendants and voice access numbers have their own as well. The only place where extensions are used is on exchange UM mailboxes for auto-attendant dialing, and the extension is derived from +88299011085XXXX where the extension is their personal four ending digits.
    Tuesday, March 26, 2013 6:37 PM
  • Check that you have configured Announcements for Unassigned Numbers.

    http://technet.microsoft.com/en-us/library/gg425944.aspx


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Wednesday, March 27, 2013 3:53 AM
  • I have tried with both configurations; redirecting to exchange auto-attendant or by using a configured announcement on lync announcement service. The behavior is the same regardless of which one I use. As I stated before, in both cases the configured target responds (either the AA or the announcement service) when calling from a lync client, but when calling from the pstn gateway to an unassigned number the call routes back to the gateway.
    Wednesday, March 27, 2013 10:17 AM
  • I've just encountered the same issue.  Did you ever find a resolution? Were you running Lync 2013 RTM or CU1?
    Tuesday, May 7, 2013 6:34 PM
  • I never did find a solution for this, or even a proper workaround (I could configure the asterisk to respond to unassigned numbers but that would be a major pain for obvious reasons...). As I stated in another post that dealt with this very same issue, unless a dev from either asterisk project or microsoft takes a personal interest in this issue I doubt a solution will be found any time soon since both sides will be blaming each other because of an "unsupported" configuration. Hopefully CU2 with skype federation etc fixes this in june by some miracle...
    Saturday, May 11, 2013 7:08 PM
  • I have an Active case open with MS.  They've been able to reproduce and see that there is an issue in the Outbound Routing behaviour in Lync 2013 and they're working on escalating the bug up to the product group.  Nothing to do with your Astrix, we encountered the issue with using a SIP trunk.
    Monday, May 13, 2013 6:32 PM
  • Found a work around. Create another trunk that has no PSTN usage records.
    Tuesday, May 14, 2013 6:36 PM
  • Thank you for informing about this. I was going crazy with this a few months back and thought it was because of incompetence on my part. If you have the time, do let me know if theres a final resolution for this at some point.
    Monday, June 3, 2013 12:31 AM
  • Hi Michael.

    How exactly did you configure this workaround? I created the second trunk, but I couldn't figure out how to do the other configurations related to it and the asterisk box still shows calls bouncing on the trunk.

    Monday, June 3, 2013 10:56 PM
  • I created a Pool trunk without any Associated PSTN Usages. Take a look at the blog post about "Lync Trunk to Trunk Call routing stops Call Park orbit lookup" - http://voipnorm.blogspot.ca/2013/05/lync-server-2013-call-park-retrieval.html This fix also worked for the Unassigned numbers.

    Monday, June 3, 2013 11:22 PM
  • I created a Pool trunk without any Associated PSTN Usages. Take a look at the blog post about "Lync Trunk to Trunk Call routing stops Call Park orbit lookup" - http://voipnorm.blogspot.ca/2013/05/lync-server-2013-call-park-retrieval.html This fix also worked for the Unassigned numbers.


    This is the trick for me - thanks!
    Wednesday, June 5, 2013 2:08 AM
  • This issue was finally solved by the July 2013 cumulative updates. Thank you for all your help along the way.
    Thursday, July 18, 2013 4:32 PM
  • I've applied CU2 to all lync servers but this issue still remains unsolved. 
    To create a pool trunk with no pstn usages is the only thing that seems to work.
    Any news if this still is an unresolved case? 

    Nahasapeemapetilon

    Wednesday, August 14, 2013 10:29 AM
  • This is a year old post, but I am having the same issue.

    I have applied the August 2014 updates to my servers and the problem is there.

    I cannot create a new pool trunk, since I already have one on the PSTN Gateway that I am using.

    Any idea?

    Thursday, August 28, 2014 12:47 AM
  • Renzo, do you have any PSTN usages on your Lync trunks?  If so, that's only used when you want to route a PSTN call through Lync (possibly to another PBX) for calls that are not for Lync accounts.
    Monday, September 8, 2014 7:10 PM
  • Hello Eric,

    Thank you for the response. I use a certified SIP Trunk Provider (IntelePeer). You are right, since there is the only PSTN gateway at this deployment, no need for PSTN usages (I had to read a lot about it, though, before removing it).

    Everything is working as expected!

    Wednesday, September 10, 2014 4:22 PM
  • Hi Eric,

    I have this problem as well. But I cannot remove my PSTN usages, since I have to route PSTN call into another pbx (switchboard).

    I have created a route with only the numbers, i wish to route to the PBX. The routing Work fine, but the unassigned numbers does not Work. Only when I remove PSTN usages from the trunk, does unassigned numbers Work, but then trunk-to-trunk doesn't Work.

    Any toughts?

    Regards

    Allan

    Tuesday, October 21, 2014 9:27 PM
  • Hello Allan.  That would be working as designed then.  If a call comes into Lync that is not assigned in Lync, it will first check if it is supposed to route it somewhere else (PSTN Usages on the Trunk).  If there is no route there then it will look at the unassigned number range. 

    Typically Lync unassigned number ranges are only those ranges that you have identified as belonging to Lync and nothing else.  If your usages tell Lync to route it somewhere else, it will.

    ....Reading your post again....If you are only routing calls for specific numbers through Lync to your other PBX, and you call a number that hits Lync but does not match the trunk PSTN usage, what do you see the call doing?

    Is your unassigned number range including some of your PSTN usages assigned to your trunk?  If so, that may not work.

    Tuesday, October 21, 2014 11:53 PM
  • Hi Eric,

    Thank you for the quick response.

    Just to make it a bit more detailed, i've add more information below.

    So, I've configured unassigned numbers for just two number in my test, +45XXXX1114 and +45XXXX1115.

    Calling these number directly from my Lync client, give me the expected result, and my call is forwarded as configured in the announcement service.

    Then I have my route to my PBX/Switchboard. In this route I am routing only +45XXXX6666 and +45XXXX6667 to the PBX. So in my trunk configuration. I've added a PSTN usage which include that route, to my trunk from my ISP. This works fine. When I call +45XXXX6666 from PSTN my call gets routed to the PBX/Switchboard.

    But when I call one of the unassigned numbers, I get a busy tone. Looking in the Lync monitor at the call, I see the below:

    If I remove the PSTN usage, with the route to my PBX/switchbord, from my trunk, unassigned number works fine, from a PSTN call, but then PSTN calls to the PBX aren't routed to my switchboard.

    Regards

    Allan

    Wednesday, October 22, 2014 7:31 AM
  • The original post person said his was resolved with a later CU. Are you on a recent or latest CU?

    When you said your call was forwarded when calling from the Lync client, do you mean it was forwarded to UM or was the announcement heard?

    I wonder if your ITSP is potentially the failure here.  If it works from the Lync client but not from the PSTN, the only real difference is that one is authenticated and one is not, assuming the routes and usages are the same.

    You are doing the routing to your PBX through Lync using the Trunk PSTN usage, correct?

    Wednesday, October 22, 2014 3:25 PM
  • Hi Allan,



    I can confirm I have the exact same scenario and issue. Running the latest CU (December one) on Lync 2013.

    I have been fitling with the info I found here but no luck: http://stoknes.wordpress.com/2013/08/31/redirecting-inbound-pstn-calls-in-lync/

    My snooper analysis suggest that the call routing never checks unassigned number table because it never get that far.
    It is as if it doesn't trust the PSTN caller(source) to route the call.


    Br.
    Daniel

    Tuesday, January 6, 2015 12:23 PM
  • I'm seeing the same behavior as well. Inbound PSTN calls to the unassigned number range are immediately looping back out to the PSTN, even with the most recent Lync Server updates installed.
    Thursday, February 5, 2015 5:38 PM
  • I see the same issue (all Lync 2013 servers with latest Lync and Windows updates).

    As soon as I configure a PSTN usage in my Trunk Configuration, calls to 'unassigned numbers' get rejected with 'The user is not authorized to call the specified number or none of the routes have a valid gateway configured.' Even if the PSTN usage is limited to a certain number which does NOT include the unassigned number I tried to call.

    Saturday, March 21, 2015 6:31 PM