WARNING - Skype for Business Server 2015 has a normalization/matching bug - problem for those with Exchange Auto Attendants RRS feed

  • Question

  • MS support has confirmed a bug in SfB that prevents proper normalization and matching on transfers from Exchange Auto Attendants.  Still working the case but wanted to warn others using Sip trunks so they hopefully avoid jumping into this problem.

    If you have Exchange auto attendants (ours are Exchange 2013) and use menu navigation to transfer to SfB users and/or response groups, the SfB front end doesn't properly normalize and match numbers.  This causes calls that previously were matched and properly routed internally under Lync 2013 server to instead be passed back out to the sip trunk provider (that is, assuming you have a route set up for either Site or Global voice policies - if you only have user policies and don't have a user policy assigned to your ExUM contact for the AA, the transfer will just fail altogether with the "blind" transfer event log error).

    Assuming that your users have publicly routable DIDs, then having a Global or Site voice policy with a route will allow AA transfers to such users to succeed, since the number will pass back out to the sip trunk provider and return right back to SfB and get routed (the normalization bug only appears to hit calls from AAs).

    If however, like us, your response groups use fake numbers that only route internally (+12345556789 for example), these transfers will still fail because the sip trunk provider won't recognize the number and will 404 the call.

    We are still working with support on figuring out:

    1) a workaround for the RG issue - granting a voice policy and/or dial plan to the ExUM contact and RG object does not help

    2) what it is that causes the SfB front end to behave differently than Lync 2013 frontends and fail to normalize and thus match the internal numbers

    Will update as we learn more.

    Friday, May 8, 2015 9:05 PM


All replies

  • Update: MS support has repro'd the bug in their lab and as a workaround has had me build up a temporary Lync 2013 standard edition server and rehome all Exchange UM contacts to it since SfB cannot properly normalize and match them.
    Sunday, May 10, 2015 9:26 PM
  • This may not work for everyone,  but I was able to work around the issue by turning on refer support on my trunks.  That seemed to allow things to transfer around properly.  Not sure on it's long term viability as my SIP provider says to turn off Refer, but it got me going until a fix is developed.
    Monday, May 11, 2015 12:58 PM
  • I am having the exact same issue,

    such a shame that after spending 7 hours with MS Support they werent able to tell me this issue exists.

    I am using office 365 exchange so I am in a bit of different situation. I will give the Refer option a go and update you all.


    Tuesday, May 12, 2015 3:23 AM
  • I would use caution on enabling SIP REFER if using a ITSP certified provider as it is not supported.  It may cause other unexpected behavior.

    Dino Caputo, BA | MCSE | MCTS:OCS/Lync http://www.ucguys.com http://www.enableUC.com

    Tuesday, May 12, 2015 3:46 AM
  • I would use caution on enabling SIP REFER if using a ITSP certified provider as it is not supported.  It may cause other unexpected behavior.

    Dino Caputo, BA | MCSE | MCTS:OCS/Lync http://www.ucguys.com http://www.enableUC.com

    Agreed, for most people refer will actually *cause* similar symptoms.
    Tuesday, May 12, 2015 4:16 AM
  • Hi Dino,

    I agree, I just did test enabling the SIP Refer and it did work in allowing AA to transfer calls, however, I have turned it back off now. I have removed the AA from the equation for now and have forwarded the calls directly to receptionists in both US and Canada locations. 

    I was planning to do some testing tomorrow and weigh other options. You are familiar with Thinktel and Intelepeer, do you believe they have issues with supporting Refer?

    Thank you, and hope to see your blog about it.

    Tuesday, May 12, 2015 5:01 AM
  • I've not used thinktel, but IntelePeer will have issues.
    Tuesday, May 12, 2015 5:04 AM
  • Thank you,

    I have got my case with Microsoft escalated and will be working with MS about it tomorrow. I am sure this bit of info from you, through this thread, will save me many hours of trying to get my point across. 

    I will also contact Intelepeer and Thinktel tomorrow and post the updates here. my solution perhaps would also be to set up a couple more FE's with Lync 2013 and home the exum's on that one. 

    lets see what happens.

    Tuesday, May 12, 2015 5:10 AM
  • Both will say its not supported.  We would need the ITSP's to weigh in and list what problems this will cause but the biggest one is the dropped calls from clients attempting to communicate directly with the ITSP.

    The current workaround I'm hearing of is what pesospesos has done (build up new Lync 2013 SE server and home EXUM contact objects there. 

    Dino Caputo (Skype for Business MVP, BA | MCSE | MCTS:OCS/Lync) http://www.ucguys.com http://www.enableUC.com

    Tuesday, May 12, 2015 5:01 PM
  • Which Dial Plan is your normalization rule residing?  If memory serves, Exchange falls under the Global Dialplan, so if nothing for that extension is normalizing to an internal number, then it's probably falling to a National normalization rule.

    Just moved our UM contacts over, we're transitioning from Lync 2013 Std to SfB 2015 Std with Exchange 2013 CU6.  Our AA, SA and RG's all have proper DID's.  No issues with our SA or AA or Response Groups.  Haven't completed 100% testing, but out of the gate things look good.

    Wednesday, May 13, 2015 2:01 AM
  • Hi Korbyn, I'm guessing that by proper DID you mean real public routable DID.  In this case you won't necessarily notice the issue because your front end will pass the call back out to your sip trunk provider who will then route it right back to you again for delivery to the DID.  This is why our users could get transferred to (routable DIDs) and transfers to our RGs (fake DIDs) fail - it's also why the issue missed our initial testing as I wrongly assumed that the user transfer tests I did meant that all transfers were fine!

    I imagine that if you run a trace you'll see the behavior indicated - it's been confirmed now by escalated support engineers.

    Regarding normalization, my understanding (and what was borne out in testing and tracing together with MS) is that a site dial plan will get used if the AA is not granted a user dial plan, or in that situation the global dial plan will get used if there is no site dial plan.  Ultimately it doesn't matter under SfB, since the normalization doesn't actually occur!

    I'll try to spend some time cleaning up our Lync and SfB traces to remove non-public information so I can post them.

    Wednesday, May 13, 2015 3:41 AM
  • we'll do some sip traces tomorrow. Maybe I'm not fully understanding, in my testing I punched in the 4digit extension and normalization happened. Now, we are still routing out TT SIP trunk through a Lync 2013 mediation server, tomorrow is my hope to have our SfB mediation server up and running and will be retesting.
    Wednesday, May 13, 2015 4:54 AM
  • Looking forward to seeing what you come up with.  This is what MS highlighted to demo the issue - working Lync 2013 trace first:

    Lync 2013 working log


    Refer from the UM server


    TL_INFO(TF_PROTOCOL) [0]19E0.3E3C::05/07/2015-21:18:47.724.0021e268 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[343624304] $$begin_record

    Trace-Correlation-Id: 343624304

    Instance-Id: 12C90C5

    Direction: incoming

    Peer: w-ex2.domain.com:49899

    Message-Type: request

    Start-Line: REFER sip:emed.domain.com@domain.com;gruu;opaque=srvr:MediationServer:ENxdyhsd8VeqAxxfLOU7_wAA;grid=60925f273c2f4da3a338a112cfbe2954 SIP/2.0

    FROM: <sip:+16176176176@domain.com;user=phone>;epid=D54E97422B;tag=a0b611bc8

    TO: <sip:+18080808080@domain.com;user=phone>;epid=2D74213354;tag=85158226bc

    CALL-ID:  a205a469-e144-4ad2-bcd6-1b36be61a5b2


    CONTACT:  <sip:w-ex2.Domain.com:5068;transport=Tls;ms-opaque=719226fc0e4a5707>;automata;text;audio;video;image

    VIA:  SIP/2.0/TLS;branch=z9hG4bKff1532ba

    ROUTE:  <sip:elync.Domain.com:5061;transport=tls;opaque=state:F;lr>



    REFERRED-BY:  <sip:YUBOSAA@domain.com>;ms-referee-uri="sip:+18080808080@domain.com;user=phone";ms-identity="MIIBtwYJKoZIhvcNAQcCoIIBqDCCAaQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAYMwggF/AgEBMFwwRTETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBlllYXJVcDEWMBQGA1UEAxMNWWVhclVwLURDMS1DQQITWwAABbyj9bsUuYh67QAAAAAFvDAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBABpIbynJ+2RaxBNEOJ18mSGG0WE1LoUJ/zAZOfHgaQ5rYhiVgvmaTjRmWFcyU3QFhp5k7NO5TgSj5PrnnGllYVJa5gsiL5ZPAPeV6tvnjVs//RmFu/xaSbTCY1T6s9ebcRR3CTh4NXqvXJrP0c5Gg1AisBibJm2MoYyCQKfny3VmZ2bkrbBA3Tb4gZPUJFQ6gvXDxwIn6iTwcf4gzFWhox7AGLXioI0e0dY9rHkMhxiNu+0V5pGU0tQKchgIYh2zzjwR3DSr1yRIQIdLdGZx/C6ZPkVff2MUc0v8KvJigDxiudoNMh6ZGpsFPRsk/gXJ+eSItbQog9QqKCNULjN3w=:Thu, 07 May 2015 21:18:47 GMT";ms-identity-info="sip:w-ex2.Domain.com:5068;transport=Tls";ms-identity-alg=rsa-sha1

    REFER-TO:  <sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>

    P-ASSERTED-IDENTITY:  <sip:YUBOSAA@domain.com>



    Invite out to the Refer-to number


    TL_INFO(TF_PROTOCOL) [1]19E0.3E3C::05/07/2015-21:18:47.986.0022085c (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1935453861] $$begin_record

    Trace-Correlation-Id: 1935453861

    Instance-Id: 12C90CA

    Direction: incoming

    Peer: emed.domain.com:49567

    Message-Type: request

    Start-Line: INVITE sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring SIP/2.0

    FROM: "WirelessCaller"<sip:+18080808080@domain.com;user=phone>;epid=2D74213354;tag=87fe9f838

    TO: <sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>

    CALL-ID:  27c873f5-53e3-411b-9421-db81c70e33a8

    CSEQ: 111881 INVITE

    CONTACT:  <sip:emed.domain.com@domain.com;gruu;opaque=srvr:MediationServer:ENxdyhsd8VeqAxxfLOU7_wAA;grid=60925f273c2f4da3a338a112cfbe2954>;isGateway

    VIA:  SIP/2.0/TLS;branch=z9hG4bK508ffb



    CONTENT-TYPE:  multipart/alternative; boundary=tQzXfhvMQQYkXbJmIzImxz8E3FweT6Ev

    REFERRED-BY:  <sip:YUBOSAA@domain.com>;ms-referee-uri="sip:+18080808080@domain.com;user=phone";ms-identity="MIIBtwYJKoZIhvcNAQcCoIIBqDCCAaQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAYMwggF/AgEBMFwwRTETMBEGCgmSJomT8ixkARkWA29yZzEWMBQGCgmSJomT8ixkARkWBlllYXJVcDEWMBQGA1UEAxMNWWVhclVwLURDMS1DQQITWwAABbyj9bsUuYh67QAAAAAFvDAJBgUrDgMCGgUAMA0GCSqGSIb3DQEBAQUABIIBABpIbynJ+2RaxBNEOJ18mSGG0WE1LoUJ/zAZOfHgaQ5rYhiVgvmaTjRmWFcyU3QFhp5k7NO5TgSj5PrnnGllYVJa5gsiL5ZPAPeV6tvnjVs//RmFu/xaSbTCY1T6s9ebcRR3CTh4NXqvXJrP0c5Gg1AisBibJm2MoYyCQKfny3VmZ2bkrbBA3Tb4gZPUJFQ6gvXDxwIn6iTwcf4gzFWhox7AGLXioI0e0dY9rHkMhxiNu+0V5pGU0tQKchgIYh2zzjwR3DSr1yRIQIdLdGZx/C6ZPkVff2MUc0v8KvJigDxiudoNMh6ZGpsFPRsk/gXJ+eSItbQog9QqKCNULjN3w=:Thu, 07 May 2015 21:18:47 GMT";ms-identity-info="sip:w-ex2.Domain.com:5068;transport=Tls";ms-identity-alg=rsa-sha1


    Progress report


    TL_INFO(TF_PROTOCOL) [2]19E0.3E3C::05/07/2015-21:18:48.020.00223bcb (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1935453861] $$begin_record

    Trace-Correlation-Id: 1935453861

    Instance-Id: 12C90CD

    Direction: outgoing;source="local"

    Peer: emed.domain.com:49567

    Message-Type: response

    Start-Line: SIP/2.0 101 Progress Report

    From: "WirelessCaller"<sip:+18080808080@domain.com;user=phone>;epid=2D74213354;tag=87fe9f838

    To: <sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>

    Call-ID: 27c873f5-53e3-411b-9421-db81c70e33a8

    CSeq: 111881 INVITE

    Via: SIP/2.0/TLS;branch=z9hG4bK508ffb;ms-received-port=49567;ms-received-cid=259C500

    Content-Length: 0

    ms-diagnostics: 14011;reason="Called Number translated";source="ELYNC.DOMAIN.com";RuleName="11digit";CalledNumber="16175558958";TranslatedNumber="+16175558958";appName="TranslationService"



    In Translation logs we can see that the translation service is requesting for default profile and normalizing the number


                                  OnRequest: INVITE, reqUri=sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring newHostPart=NULL

                                  Processing From URI: sip:+18080808080@domain.com;user=phone

                                  Global number, no further From URI processing. FromUri=tel:+18080808080              


                                  (0000000003CA630E)Enter. [name=DefaultProfile, signature=53761a00-348d-4301-9af0-653af524dede]

                                  ruleName='11digit' matched Num='16175558958', txNum='+16175558958'

                                  MATCH: New request Uri='sip:+16175558958@domain.com;user=phone;phone-context=dialstring'

                                  Retargeting [ReqUri=sip:+16175558958@domain.com;user=phone;phone-context=dialstring]


    Then the request was forwarded to the Response Group service


    TL_INFO(TF_PROTOCOL) [1]19E0.39B8::05/07/2015-21:18:48.255.00229dd1 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1935453861] $$begin_record

    Trace-Correlation-Id: 1935453861

    Instance-Id: 12C90DD

    Direction: incoming

    Peer: elync.domain.com:5071

    Message-Type: response

    Start-Line: SIP/2.0 200 OK

    FROM: "WirelessCaller"<sip:+18080808080@domain.com;user=phone>;tag=87fe9f838;epid=2D74213354

    TO: "BOSCorpEngIntBoxHunt@domain.com"<sip:16175558958;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>;tag=69917221a0;epid=74F7C678E4

    CALL-ID:  27c873f5-53e3-411b-9421-db81c70e33a8

    CSEQ: 111881 INVITE

    CONTACT:  <sip:elync.domain.com@domain.com;gruu;opaque=srvr:Microsoft.Rtc.Applications.Acd:dZ0dakY_IFy2Kacx5S_W9QAA>;automata;actor="attendant";text;audio;video;image;applicationsharing

    VIA:  SIP/2.0/TLS;branch=z9hG4bK54FBF83E.2A41EE723739A468;branched=FALSE,SIP/2.0/TLS;branch=z9hG4bK508ffb;ms-received-port=49567;ms-received-cid=259C500

    RECORD-ROUTE:  <sip:elync.Domain.com:5061;transport=tls;opaque=state:F;lr>;tag=AC20A314D1E8C5EEC52C7E4296B639F9


    CONTENT-TYPE:  application/sdp

    ms-diagnostics:  24100;Component="RTCC/";Reason="General diagnostic information.";CalleeICEWarningFlags="Audio:ICEWarn=0x0,LocalSite=,LocalMR=,RemoteSite=,RemoteMR=,PortRange=49152:57500,LocalMRTCPPort=59007,RemoteMRTCPPort=51039,LocalLocation=2,RemoteLocation=2,FederationType=0,Interfaces=0x2,BaseInterface=0x2,BaseAddress=";Source="elync.Domain.com"

    P-ASSERTED-IDENTITY:  "BOSCorpEngIntBoxHunt@domain.com"<sip:BOSCorpEngIntBoxHunt@domain.com>,<tel:+16175558958>

    Wednesday, May 13, 2015 9:44 AM
  • And the broken SfB flow:

    SFB non-working


    Refer from the UM server


                                  TL_INFO(TF_PROTOCOL) [efe\efe]1978.1A04::05/08/2015-10:07:53.559.00008CAD (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [1935614983]

    Trace-Correlation-Id: 1935614983

    Instance-Id: 317A51

    Direction: incoming

    Peer: e-ex1.domain.local:44763

    Message-Type: request

    Start-Line: REFER sip:emed.domain.local@domain.com;gruu;opaque=srvr:MediationServer:sAhKNnbx2lCcWC947L2wDAAA;grid=31bfdac9726341889a248da5a8f1c714 SIP/2.0

    FROM: <sip:13123123123;phone-context=DefaultProfile@domain.com;user=phone>;epid=C812765A5F;tag=3c9dd37bf0

    TO: <sip:8080808080;phone-context=DefaultProfile@domain.com;user=phone>;epid=2C3539584A;tag=c6c311992b

    CALL-ID: 87a41359-63e7-4ef6-9dd1-077506c650b0


    CONTACT: <sip:e-ex1.domain.local:5066;transport=Tls;ms-opaque=1995d0ef3e6ba366>;automata;text;audio;video;image

    VIA: SIP/2.0/TLS;branch=z9hG4bK86d4cd

    ROUTE: <sip:efe.domain.local:5061;transport=tls;opaque=state:F;lr>



    REFERRED-BY: <sip:ORGinUMChicagoAA@domain.com>;ms-identity="MIIBtQYJKoZIhvcNAQcCoIIBpjCCAaICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAYEwggF9AgEBMFowQzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRQwEgYKCZImiZPyLGQBGRYEbHVuZzEUMBIGA1UEAxMLbHVuZy1EQzEtQ0ECExwAAAAIm+BbYjG8S+IAAAAAAAgwCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQB3MIE7l297rfCMu3i2mtgHLr8ZF9Aj9PWeFrcZiObdYdGEsUHibzYJJs7eUs/kcWPKKEXC8lqu/YIGr5imES9i5vJEFP4m6ADKF+LRQ4HyfBJ6Y1g4I2+bBjpEHvMehHcclZxWPbG4T6XD9N1cgoEpe61TVI4U+4o3A4/d6av0MsjHTAy5uzENgi57plnKlGnrjusOm/Wd+yP8mDOt8Te9lZ9AsOMUYlgWfrVoSD8Pls09NFj1kOVyvzIk4H6Ia+fvMlZhh4FF3e3BkneK17a6a5p1YDVJ0nu+mTg6nN7ihh4NVFQrfWi3CZ05mD6p6WaeQ1PYsUg0Cqvo/tzwpI:Fri, 08 May 2015 10:07:53 GMT";ms-identity-info="sip:e-ex1.domain.local:5066;transport=Tls";ms-identity-alg=rsa-sha1

    REFER-TO: <sip:13125559951;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>

    P-ASSERTED-IDENTITY: <sip:ORGinUMChicagoAA@domain.com>

    TL_INFO(TF_COMPONENT) [emed\emed]0AA0.0C54: :05/08/2015-10:07:53.561.0000286D (S4,NegotiateLogic.constructor:negotiatelogic.cs(280)) constructed


    Invite out to the Refer-to number


                            TL_INFO(TF_PROTOCOL) [emed\emed]0AA0.0808::05/08/2015-10:07:53.827.0000289D (S4,SipMessage.DataLoggingHelper:sipmessage.cs(801)) [4040348151]

    >>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_FB181A>],>

    INVITE sip:13125559951;phone-context=user-default@domain.com;user=phone;phone-context=dialstring SIP/2.0

    FROM: <sip:8080808080;phone-context=DefaultProfile@domain.com;user=phone>;epid=2C3539584A;tag=f43864b050

    TO: <sip:13125559951;phone-context=user-default@domain.com;user=phone;phone-context=dialstring>

    CSEQ: 16527 INVITE

    CALL-ID: 87dbd18d-f30b-4e88-829f-59acc60df19a


    VIA: SIP/2.0/TLS;branch=z9hG4bK86a7412b

    CONTACT: <sip:emed.domain.local@domain.com;gruu;opaque=srvr:MediationServer:sAhKNnbx2lCcWC947L2wDAAA;grid=31bfdac9726341889a248da5a8f1c714>;isGateway


    REFERRED-BY: <sip:ORGinUMChicagoAA@domain.com>;ms-identity="MIIBtQYJKoZIhvcNAQcCoIIBpjCCAaICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGCAYEwggF9AgEBMFowQzEVMBMGCgmSJomT8ixkARkWBWxvY2FsMRQwEgYKCZImiZPyLGQBGRYEbHVuZzEUMBIGA1UEAxMLbHVuZy1EQzEtQ0ECExwAAAAIm+BbYjG8S+IAAAAAAAgwCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQB3MIE7l297rfCMu3i2mtgHLr8ZF9Aj9PWeFrcZiObdYdGEsUHibzYJJs7eUs/kcWPKKEXC8lqu/YIGr5imES9i5vJEFP4m6ADKF+LRQ4HyfBJ6Y1g4I2+bBjpEHvMehHcclZxWPbG4T6XD9N1cgoEpe61TVI4U+4o3A4/d6av0MsjHTAy5uzENgi57plnKlGnrjusOm/Wd+yP8mDOt8Te9lZ9AsOMUYlgWfrVoSD8Pls09NFj1kOVyvzIk4H6Ia+fvMlZhh4FF3e3BkneK17a6a5p1YDVJ0nu+mTg6nN7ihh4NVFQrfWi3CZ05mD6p6WaeQ1PYsUg0Cqvo/tzwpI:Fri, 08 May 2015 10:07:53 GMT";ms-identity-info="sip:e-ex1.domain.local:5066;transport=Tls";ms-identity-alg=rsa-sha1

    SUPPORTED: replaces

    SUPPORTED: ms-safe-transfer

    SUPPORTED: ms-bypass

    SUPPORTED: ms-dialog-route-set-update

    SUPPORTED: timer

    SUPPORTED: 100rel

    SUPPORTED: gruu-10

    USER-AGENT: RTCC/ MediationServer

    CONTENT-TYPE: application/sdp



    ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet


    Session-Expires: 1800

    Min-SE: 90


    In Translation logs, SFB complains that the User is not homed on that Server


                            [541655698]Retargeting [ReqUri=sip:+13123123123@domain.com;user=phone]

                                  [2248162531]user-default requested in a pool that is not primary or backup of that user

                                  [2248162531]Retargeting [ReqUri=sip:13125559951;phone-context=user-default@domain.com;user=phone;phone-context=dialstring]

                                  [2855946156]user-default requested in a pool that is not primary or backup of that user

                                  [2855946156]Retargeting [ReqUri=sip:13125559951;phone-context=user-default@domain.com;user=phone;phone-context=dialstring]

    Wednesday, May 13, 2015 9:44 AM
  • My apologies, had a good sleep, fresh eyes, missed the part about using the AA to transfer to a RGS via a non-PSTN number. We currently do not have this scenario set up, but if I have time I will attempt to.

    So the scenario you might have is an AA with Press 1 for Sales, 2 for Service... and Sales is then supposed to route to extension 95101, which is a RGS Hunt Group or IVR with a phone number of +95101.  And you do have a Normalization rule either in Global or a policy assigned, that normalizes 95101 to +95101?  which fails because Sfb is routing it to the Trunk which the ITSP has no idea what to do with and bounces it.

    BUT, if it normalizes to +14163495101 let say, and that's the number on the RSG, it still routes to the ITSP trunk but essentially comes back in.  If this is the scenario, I guess this would also consume two additional Channels on the SIP trunk.

    Are you using Direct SIP or a Gateway like AudioCodes between Sfb and Intelepeer/TT?  And Media Bypass enabled or disabled?

    ok, yuck.  I feel for the engineer tracking down that loop in the code.

    Wednesday, May 13, 2015 3:54 PM
  • Microsoft confirmed that this issue DOES indeed exist. and that there is no solution for it. 

    Of course, as we all know, Microsoft's support sucks and its been almost 24 hours since then and no response from them.

    pesospesos, what kind of support case did you open with Microsoft? I have not been able to get proper support for days now. Do you have a premier support or did you open a regular case?

    My second issue is that I am using office 365 exchange and the support engineers have issues wrapping their head around it.

    Wednesday, May 13, 2015 5:53 PM
  • Korbyn, we have direct trunks - no gateway or other hardware on our side.  No media bypass.

    Atif, the case is with premier and the rep has engaged the beta SfB support team as well I believe.

    Wednesday, May 13, 2015 11:23 PM
  • That makes perfect sense now.

    We dont have premier support and have open a paid case, and as a result I am fighting everyday over the phone with some Idiot, I would appreciate if you keep us updated here.

    Thank you very much.

    Thursday, May 14, 2015 12:21 AM
  • If anyone else is using the work around of temporarily forwarding calls to a receptionist, we are giving licenses to use AttendantPro receptionist/switchboard software for anyone that wants it to use till the fix is here. http://landiscomputer.com/AttendantPro (we will extend the keys for you as long as needed) 

    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    Thursday, May 14, 2015 1:15 PM
  • Update:

    After one week of engaging Microsoft support, they finally confirmed the workaround that was suggested here in this thread i.e. spinning up a new Lync 2013 and homing the contacts there.

    However, this may not work for those who use office 365 Exchange. After spinning a new pool of lync 2013, and creating new csexumcontacts on it, there is no difference in behavior.

    Just a heads up for others (for now)

    Saturday, May 16, 2015 2:30 PM
  • Thanks for that heads up @atif7865

    +Say thanks and observe basic forum courtesy:
    +If this post answered your question, Mark As Answer
    +If this post was helpful, Vote as Helpful

    windowspbx blog: my thots/howtos
    see/submit Lync suggestions here: simple and public

    Saturday, May 16, 2015 2:33 PM
  • Support let me know that a fix is planned for the "next SfB update."  I have asked when that is estimated to drop.
    Tuesday, May 19, 2015 9:48 PM
  • Fix is slated for "q3 2015." Hopefully soon.
    • Marked as answer by Eric_YangK Sunday, May 31, 2015 12:53 PM
    • Unmarked as answer by Wes Wes Wes Sunday, May 31, 2015 6:33 PM
    Wednesday, May 20, 2015 9:58 PM
  • Has anyone managed a workaround other than to create a lync 2013 pool?
    I updated to SfB yesterday and didn't know of this bug which is causing me a massive headache
    Friday, May 29, 2015 7:47 AM
  • Microsoft, stop marking unfinished threads as answered.

    Stating that there is supposedly going to be a fix in q3 is not an answer to this question, and closing the thread prevents others from seeing that it is an open issue and hopefully avoiding the problem.

    There still doesn't even appear to be a proper KB article for this issue yet.

    Sunday, May 31, 2015 6:34 PM
  • That what "THESE PEOPLE" do. 

    They go around and just put some garbage in the thread and mark it as answered. I have to go back and mark ti as un-answered. Microsoft is paying these idiots for this job.

    I have had to install Lync 2013 and it has worked for me too. Initially it didnt but there was a configuration issue (again i relied on Microsoft) that had caused this. bottom line the workaround works.


    Thursday, June 18, 2015 5:18 PM
  • KB finally added today.  No mention of a fix schedule yet.


    Friday, June 19, 2015 8:19 PM
  • Looks like the issue is listed as fixed in the Skype for Business server CU that just came out: https://support.microsoft.com/en-us/kb/3061059

    Please mark posts as answers/helpful if it answers your question.
    Lync Validator - Used to assist in the validation and documentation of Lync Server 2013.

    Saturday, June 20, 2015 6:05 PM
  • CU seems to have fixed the issue for us.
    Sunday, June 21, 2015 8:11 AM
  • I was still having this issue after latest update. 

    If anyone else is still having issues with this (SfB 2015 & Exchange UM 2010), the resolution that worked for me was:

    • AutoAnswer number:  +15554443333
    • UM Dial Plan: 4 digits
    • AutoAnswer Keymap (Press 1 for X): 12345
    • Response Group #: +12345

    Add a normalization rule for your Response group number (12345):

    • Pattern to match: ^(12345)$ 
    • Translation pattern: +$1

    Setup Dialing Restrictions:

    • Dialing Plan Properties -> Dialinig Rule Groups -> Add...
    • Name: Somethinguseful
    • Number mask:  12345
    • Dialed number:  12345
    • Dialing Restrictions -> Add... (add in newly created rule group)
    • Repeat for your AA in UM Auto Attendant Properties

    Note:  I'm not sure it matters that the Dial plan # digits is 4, and the keymap extension must be different length, but that's what I had.  Use as example for your environment.


    Monday, January 18, 2016 7:17 PM