locked
Problem transfering call - REFER-TO header sending server FQDN instead of dialed number RRS feed

  • Question

  • Hi!

    A customer of mine is using Skype for Business and Avaya and we've come across the following problem:

    When a user receives or places a call with someone outside of SfB (Avaya or PSTN) and then tries to refer to a co-worker it doen't work. All other kinds of call work fine.

    I've logged the call with Wireshark and Centralized Logging and noticed that inside of SfB everything is great, but in Wireshark I see the following:

    <sip:[Server-FQDN]:5068;transport=Tcp;maddr=[IP-Address];ms-opaque=a1ea6e5ce57b4a0a?REPLACES=5ad7b599db034e0d9782e8666e8addbf%3Bfrom-tag%3Df89bb2ef1d%3Bto-tag%3Ded98bde610>

    Centralized Logging is showing me:

    Refer-to: <sip:+[Phonenumber]@[Domain];user=phone>

    I've also noticed some discrepancies in the Session-ID and port-numbers, so I'm guessing that what Centralized Logging is showing me is the communication between the FE and the Mediation Server, which are both on the same computer.

    The trunk settings are as follows:

    Refer support: Enable sending refer to the gateway
    Enable media bypass: false
    Centralized media processing: true
    Enable RTP latching: false
    Enable forward call history: true
    Enable forward P-Asserted-Identity data: false
    Enable outbound routing failover timer: true

    Has anyone here ever had this problem? Any solutions?

    Thanks in advance!

    Regards,

    Gerrit Deike (MCT, MCSE:Messaging/Communication/Productivity)


    If you think your to small to make a differnce, try going to bed with a mosquito in the room...

    Tuesday, August 1, 2017 11:48 AM

All replies

  • Hi Gerrit,

     

    To further troubleshoot the issue, can you please confirm the following information?

    1. Outside call was through the SFB client or IP phone?
    2. All users can’t transfer outside call in you environment?

     

    Please check whether or not the SIP trunk provider supports SIP Refer support.

     

    If you SIP trunk provider not support the SIP Refer support, please set Refer support: none

    Perform the following steps from the SFB Server Control Panel:

           1.Choose the Voice Routing menu item from the SFB Server Control Panel menu

           2.On the Voice Routing menu click on Trunk Configuration

           3.Select the SFB Server Global, Site, or Pool Trunk Configuration policy that requires the update

          4.Use the Edit drop down menu to choose the Edit details… menu option

           5.set the Refer support is none and then click OK

           6.Use the Commit drop down menu to invoke the Commit all option

    Note The Trunk Configuration updates described above may take a few minutes to take effect


    Best Regards,

    Leon-Lu
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    • Proposed as answer by zaikun Wednesday, November 21, 2018 4:55 PM
    Wednesday, August 2, 2017 9:02 AM
  • You may enable "Enable forward P-Asserted-Identity data: false to Enable forward P-Asserted-Identity data: TRUE"

    and capture call logs from client's PC using snooper and from SFB's voice gateway so that we can pieces thing up where the problem lies. 

    Wednesday, August 2, 2017 12:46 PM
  • Hi Leon-Lu,

    The outside call was a Mobile Phone calling through the Avaya and being routed to SfB. The internal Client was the SfB Client 2016.

    Refer support was turned off and I've tried turning it on, without any change to the problem.

    As far as I understand P-Asserted-Identity has nothing to do REFER-TO, so why should we turn it on? The error is quite clearly that REFER-TO is not being populated correctly by the Mediation Server, even though it does have the correct values within SfB.

    Cheers,

    Gerrit


    If you think your to small to make a differnce, try going to bed with a mosquito in the room...

    Wednesday, August 2, 2017 1:18 PM
  • Hi Gerrit,

    I will do some research and response to you.


    Best Regards,

    Leon-Lu
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, August 7, 2017 12:01 PM
  • Hi Gerrit,

    Could you give me some event log in mediation server and FE server?

    All external users can’t transfer outside call in you environment?

    If a few users have this problem ,it may cause by the users personal setting. If all users have this problem, it could cause some wrong setting in server.


    Best Regards,

    Leon-Lu
    TechNet Community Support


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, August 16, 2017 11:08 AM
  • Deleted
    Wednesday, August 16, 2017 12:38 PM
  • I recently experienced the same issue with one of our branches and it turned out to be the option "-enablerefersupport" on two trunks.

    after settings this to $false, it worked like a charm!

    how did we find out?

    looking into snooper: one branch it worked -> it was an invite when we tried to transfer the call. on the other non-working branch it was a "refer to" instead.

    kind regards

    Wednesday, November 21, 2018 4:55 PM