locked
A/V Skype Edge issue with Skype Web App RRS feed

  • Question

  • Hello,

    I am facing an issue with A/V with the Skype Web App.

    The issue : 

    External user using the skype web app plugin can join the meeting (IM) but can't start an A/V call. The call failed because of network issue.

    The question :

    With Snooper, I noticed that I get only local address in the "a=candidate" fields of the INVITE messages of the external user using the Skype Web App.
    I have no public IP of my Edge Server netiher any "RemoteMR".

    Does it normal? And if not, how the "a=candidate" are founded? How can I modify it in order to get the right offer?

    The topology :

    I have one front end pool with 3 front end server and one Edge pool with 2 edge servers behind NAT and with DNS load balancing.

    The SIP message received by my internal client (with the good a=remote candidate) :

    TL_INFO(TF_PROTOCOL) [frontEnd-pool\FrontEnd1]174C.1E10::09/28/2018-09:45:30.362.00AFD8EF (S4,SipMessage.DataLoggingHelper:sipmessage.cs(801)) [2636272821]
    >>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_1FA410D>], 10.1.50.1:5063->10.1.50.1:64617
    SIP/2.0 200 OK
    FROM: "bml"<sip:4fc1704d-221f-4d16-a53e-77355299bd2b@anonymous.invalid>;tag=43d0d7a22f;epid=091052A8DC
    TO: <sip:internalUser@contoso.com;gruu;opaque=app:conf:audio-video:id:FNY8Z24H>;tag=8c39847f74;epid=C6EA6FBD66
    CSEQ: 2211 INVITE
    CALL-ID: 8c39a987-dbae-42bd-87ac-72c7b16a5e90
    VIA: SIP/2.0/TLS 10.1.50.1:64617;branch=z9hG4bK9B5665D1.5C044267E9F55AAA;branched=FALSE,SIP/2.0/TLS 10.1.50.1:65361;branch=z9hG4bKd4e3404c;ms-received-port=65361;ms-received-cid=628D00
    RECORD-ROUTE: <sip:frontEnd-pool.contoso.lan:5061;transport=tls;ms-fe=FrontEnd1.contoso.lan;opaque=state:F;lr>;tag=13B26E67793ECF498834AF5B5AF72FEF
    CONTACT: <sip:internalUser@contoso.com;gruu;opaque=app:conf:audio-video:id:FNY8Z24H>;isFocus
    CONTENT-LENGTH: 1167
    SUPPORTED: ms-dialog-route-set-update
    SUPPORTED: gruu-10
    SUPPORTED: timer
    CONTENT-TYPE: application/sdp
    ALLOW: ACK
    ALLOW: CANCEL,BYE,INVITE,UPDATE
    SERVER: RTCC/6.0.0.0 AV-MCU
    ms-diagnostics: 7037;source="FrontEnd1.contoso.lan";reason="Media stack diagnostics info";component="Audio Video Conferencing Server";BaseAddress="10.1.50.1:49421";LocalSite="10.1.50.1:49323";RemoteSite="172.20.10.7:7594";MediaEpBlob="ICEWarn=0x0,ICEWarnEx=0x1,LocalMR=62.XXX.XXX.XXX:50496,PortRange=49152:57500,LocalMRTCPPort=52340,LocalLocation=2,RemoteLocation=2,FederationType=0,StunVer=0,CsntRqOut=0,CsntRqIn=0,CsntRspOut=0,CsntRspIn=0,Interfaces=0x2,BaseInterface=0x2,IceRole=1,RtpRtcpMux=1,AllocationTimeInMs=216,FirstHopRTTInMs=2,TransportBytesSent=0,TransportPktsSent=0,IceConnCheckStatus=0,PrelimConnChecksSucceeded=0,IceInitTS=3747116738436,ContactSrvMs=180,AllocFinMs=236,FinalAnsRcvMs=1,BlobGenTime=3747116738687,MediaDllVersion=6.0.8953.265,BlobVer=1";MPServiceInfo="net.pipe://localhost/MPService/MediaProcessor/pipe5964"
    ms-diagnostics-public: 7037;reason="Media stack diagnostics info";component="Audio Video Conferencing Server"
    ms-endpoint-location-data: NetworkScope;ms-media-location-type=intranet
    Session-Expires: 1800;refresher=uac
    Min-SE: 90
    v=0
    o=- 99 0 IN IP4 10.1.50.1
    s=session
    c=IN IP4 10.1.50.1
    b=CT:1000000
    t=0 0
    m=audio 56311 RTP/SAVP 9 111 0 8 97 13 118 101
    c=IN IP4 10.1.50.1
    a=rtcp-rsize
    a=rtcp-fb:* x-message app send:dsh recv:dsh
    a=x-ssrc-range:1011-1011
    a=x-source-streamid:12
    a=rtcp:56311
    a=ice-ufrag:RceS
    a=ice-pwd:A10Lm44sUrsDcdOIRgZ722NF
    a=rtcp-mux
    a=candidate:1 1 UDP 2130706431 10.1.50.1 56311 typ host
    a=candidate:2 1 tcp-pass 174456319 62.XXX.XXX.XXX 52340 typ relay raddr 10.1.50.1 rport 49323
    a=candidate:3 1 UDP 184548351 62.XXX.XXX.XXX 50496 typ relay raddr 10.1.50.1 rport 49421
    a=candidate:4 1 tcp-act 174848511 62.XXX.XXX.XXX 52340 typ relay raddr 10.1.50.1 rport 49323
    a=candidate:5 1 tcp-act 1684797439 10.1.50.1 49323 typ srflx raddr 10.1.50.1 rport 49323
    a=label:main-audio
    a=cryptoscale:1 server AES_CM_128_HMAC_SHA1_80 inline:g76Y6N2IlVaTdzxAUZjEbHRRJ2XRN51bCNqJucqI|2^31|1:1
    a=x-audioflow:sendonly
    a=x-dtmfflow:recvonly
    a=rtpmap:9 g722/8000
    a=rtpmap:111 SIREN/16000
    a=fmtp:111 bitrate=16000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:8 PCMA/8000
    a=rtpmap:97 RED/8000
    a=rtpmap:13 CN/8000
    a=rtpmap:118 CN/16000
    a=rtpmap:101 telephone-event/8000
    a=ptime:20

    ------------EndOfOutgoing SipMessage

    The SIP message received by my external client (with the wrong a=remote candidate) :

    TL_INFO(TF_PROTOCOL) [frontEnd-pool\FrontEnd1]1BB4.2330::09/28/2018-09:45:30.089.00AFD8DB (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(261)) [3480979752] 
    Date: Fri, 28 Sep 2018 09:45:30 GMT
    Trace-Correlation-Id: 3480979752
    Instance-Id: 127FAA
    Direction: outgoing
    Peer: frontEnd-pool.contoso.lan:5063;ms-fe=FrontEnd1.contoso.lan
    Message-Type: request
    Start-Line: INVITE sip:frontEnd-pool.contoso.lan:5063;transport=tls;ms-fe=FrontEnd1.contoso.lan SIP/2.0
    From: "bml"<sip:4fc1704d-221f-4d16-a53e-77355299bd2b@anonymous.invalid>;epid=091052A8DC;tag=43d0d7a22f
    To: <sip:internalUser@contoso.com;gruu;opaque=app:conf:audio-video:id:FNY8Z24H>
    Call-ID: 8c39a987-dbae-42bd-87ac-72c7b16a5e90
    CSeq: 2211 INVITE
    Contact: <sip:frontEnd-pool.contoso.lan:5088;ms-fe=FrontEnd1.contoso.lan;transport=Tls;ms-opaque=33801d33c897ee37>;text;audio;video;image;application;applicationsharing
    Via: SIP/2.0/TLS 10.1.50.1:64617;branch=z9hG4bK9B5665D1.5C044267E9F55AAA;branched=FALSE
    Via: SIP/2.0/TLS 10.1.50.1:65361;branch=z9hG4bKd4e3404c;ms-received-port=65361;ms-received-cid=628D00
    Record-Route: <sip:frontEnd-pool.contoso.lan:5061;transport=tls;ms-fe=FrontEnd1.contoso.lan;opaque=state:F;lr>;tag=13B26E67793ECF498834AF5B5AF72FEF
    Max-Forwards: 69
    Content-Length: 1541
    Content-Type: application/sdp
    P-Asserted-Identity: "bml"<sip:4fc1704d-221f-4d16-a53e-77355299bd2b@anonymous.invalid>
    ms-application-via: ms-udc.cdr%3D9eee1c723f9c527b3a8b1d374aaf462c%3A6%3Bconvhist%3D0%3A6;ms-pool=frontEnd-pool.contoso.lan;ms-application=http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent;ms-server=FrontEnd1.contoso.lan
    Expires: 600
    Priority: Normal
    Supported: replaces
    Supported: ms-dialog-route-set-update
    Supported: timer
    Supported: 100rel
    User-Agent: RTCC/6.0.0.0 UCWA/6.0.0.0 LWA/6.0 (Enterprise Web App; windows 6.3; internetExplorer 7.0; os64Browser32; IsArm=false)
    Allow: ACK
    Allow: CANCEL,BYE,INVITE,REFER,MESSAGE,INFO,SERVICE,OPTIONS,BENOTIFY,NOTIFY,PRACK,UPDATE
    ms-telemetry-id: 1d730255-9f1d-4403-a779-a2b65243eda6
    ms-mcu-contact: <sip:frontEnd-pool.contoso.lan:5063;transport=tls;ms-fe=FrontEnd1.contoso.lan>
    Content-ID: f889a94b-652a-4a15-a144-6cba8cc929d2
    Ms-Conversation-ID: AdRXD/u0Ol8jQ/ca8EuegfZzRo+V9w==
    ms-endpoint-location-data: NetworkScope;ms-media-location-type=Intranet
    Session-Expires: 1800
    Min-SE: 90
    Call-Info: <sip:internalUser@contoso.com;gruu;opaque=app:conf:focus:id:FNY8Z24H>;purpose=ms-conf-uri
    Message-Body: 
    v=0
    o=- 0 0 IN IP4 172.20.10.7
    s=session
    c=IN IP4 172.20.10.7
    b=CT:99980
    t=0 0
    m=audio 7594 RTP/AVP 104 114 9 112 111 0 103 8 116 115 97 13 118 101
    a=x-ssrc-range:414585344-414585344
    a=rtcp-fb:* x-message app send:dsh recv:dsh
    a=rtcp-rsize
    a=label:main-audio
    a=x-source:main-audio
    a=ice-ufrag:kZUy
    a=ice-pwd:tp7IcVGBCX8JyIqOHTrtNDQs
    a=candidate:1 1 UDP 2130706431 172.20.10.7 7594 typ host 
    a=candidate:1 2 UDP 2130705918 172.20.10.7 7595 typ host 
    a=candidate:2 1 TCP-ACT 1684798975 172.20.10.7 7594 typ srflx raddr 172.20.10.7 rport 7594 
    a=candidate:2 2 TCP-ACT 1684798462 172.20.10.7 7594 typ srflx raddr 172.20.10.7 rport 7594 
    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:sYc4qMkske/nf90+VCZYP8eooc4IcVxpumwcKy0A|2^31|1:1
    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:h+DePRCV0liVDOVT/gZncq7vK71mPojwAAB8OJ/W|2^31|1:1
    a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:8eeoWCpZKS9FzDu6i8Z7sVw0XbMVebS1uIfG4oOp|2^31
    a=maxptime:200
    a=rtcp:7595
    a=rtpmap:104 SILK/16000
    a=fmtp:104 useinbandfec=1; usedtx=0
    a=rtpmap:114 x-msrta/16000
    a=fmtp:114 bitrate=29000
    a=rtpmap:9 G722/8000
    a=rtpmap:112 G7221/16000
    a=fmtp:112 bitrate=24000
    a=rtpmap:111 SIREN/16000
    a=fmtp:111 bitrate=16000
    a=rtpmap:0 PCMU/8000
    a=rtpmap:103 SILK/8000
    a=fmtp:103 useinbandfec=1; usedtx=0
    a=rtpmap:8 PCMA/8000
    a=rtpmap:116 AAL2-G726-32/8000
    a=rtpmap:115 x-msrta/8000
    a=fmtp:115 bitrate=11800
    a=rtpmap:97 RED/8000
    a=rtpmap:13 CN/8000
    a=rtpmap:118 CN/16000
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-16
    a=rtcp-mux
    a=ptime:20

    Thanks.

    Best regards

    Friday, September 28, 2018 1:13 PM

Answers

  • Hi,

    thanks a lot. My issue is resolved.

    The issue was my reverse proxy configuration.

    Indeed, the reverse proxy was redirected to the backend on the port 443 instead of the port 4443.

    Thanks a lot once.

    Regards,

    Monday, October 1, 2018 3:21 PM

All replies

  • Hi,

    Can your SfB clients connect externally and successfully establish A/V sessions?

    On the properties of the Edge, have you enabled NAT and specified the "NAT-enabled public IPv4 address"?

    Friday, September 28, 2018 3:28 PM
  • Hi, Thanks for your answer. Yes, m'y sfb client can connect externally and successfully establish A/V sessions without any issue. Yes, I've enabled Nat and specified the public ipv4 addres in the topology of the edge servers.
    Friday, September 28, 2018 5:32 PM
  • Hi,

    Are you using x3 IPs on each Edge?

    Is the topology like this:

    Edge Server 1

    PUBLIC IP > Static NAT > Access Edge

    PUBLIC IP > Static NAT > A/V Edge

    PUBLIC IP > Static NAT > Webconf Edge

    Then the same for Edge Server 2.

    In public DNS you round robin to the relevant IPs?

    What is 172.20.10.7, is that something on you network or the actual end user IP?

    Are the A/V Edge NAT'd IPs definitely specified correctly for each host?

    Also I'm assuming you've got a Reverse Proxy in place.

     
    Friday, September 28, 2018 5:53 PM
  • Hi,

    I use only one public IP per edge. 

    PUBLIC IP1 > Static NAT > Edge1 (A/V Edge, Web Conf and Access Edge)

    PUBLIC IP2 > Static NAT > Edge2 (A/V Edge, Web Conf and Access Edge)

    Yes, I have two public DNS with these two public IP leading to my edge servers.

    The 172.20.10.7 is the local network of my external user (I do my test with a 4G access point).

    Yes, my external client is aware about the natted ip of the edge server. Indeed, I see traffic from my external client to the natted IP of the good edge server (with wireshark).

    I see the traffic arriving on my edge server from the external client, but then the call failed.

    It seems that the internal client is not able to know where is my external client. Indeed, we see that the external client only show is local IP in the candidate (172.20.10.7). Is that normal? Should the external client shwo the public IP of the edge server in its candidates as Local media Relay?

    Yes, I have a reverse proxy in place which seems to work well.


    Monday, October 1, 2018 7:49 AM
  • Hi,

    You are seeing host candidates & reflective candidates (STUN).

    You're not getting relay candidates (TURN) i.e. the public IP of the A/V Edge.

    I'd suggest checking that the Static NAT rules are working as expected - from each Edge can you confirm that you're presenting outbound on the IP you've specified as the NAT-enabled IPv4 address.  For example go to www.whatismyip.com.

    Next I'd suggest checking again that all of the ACLs are in place relating to Edge.  Can you advise what ACLs you've configured?  Also what ports you have assigned to the External Edge?


    Monday, October 1, 2018 8:09 AM
  • Hi,

    Is it normal that I am not getting relay candidates (TURN) from my external client?

    Does the web app only work with STUN?

    As for the nat, I checked on both edge servers. They are both showing the right public IP on whatismyip.com.

    It is not surprising because we have set a 1:1 nat on the router for these public ip toward the edge server.

    As for the firwall rule, we have allowed the following ports :

    ANY > Edge Servers on the ports TCP/443, TCP/444, TCP/5061, UDP/3478, TCP/50000-59999, UDP/50000-59999

    Edge Servers > ANY on the ports TCP/443, TCP/444, TCP/5061, UDP/3478, TCP/50000-59999, UDP/50000-59999

    Then, the external interfaces of the edge servers can talk together and the front end servers can talk to the internal AND external interfaces of the edge servers.

    The ports used for the edge services are :

    - 5061 (TLS) fort the Edge Access

    - 444 (TLS) for the Web Conf 

    - 443 (TCP¨) fot the Edge A/V

    Monday, October 1, 2018 9:05 AM
  • Thanks for the detail, that all looks fine.

    You should be getting relay candidates (TURN), regardless of the client signalling path/location, media will always be handled by the Edge.  The media path is the Web App client to server, so TURN will typically be used.

    Can you add &log=full to the end of the SfB Meeting URL, then join the meeting using the SfB Web App.

    The logs, found at %AppData%\Local\Microsoft\SkypeForBusinessPlugin\Tracing may be helpful in trobleshooting further.  

    Look at the following logs: JavaScript_yyyy-mm-dd_hh_mm_ss.log & PluginHost_yyy-mm-dd_hh_mm_ss.log
    Monday, October 1, 2018 9:34 AM
  • Thanks a lot for all your responses.

    I found the followinf error in my logs of the external client using web app :

    "Complete Negotiation failed with hr code : 8007139F"

    Do you think the issue can come from my internal and external fqdn for the web services which are the same in my topology of the front end pool?

    Monday, October 1, 2018 10:15 AM
  • Yes, the Internal & External Web Services FQDNs should be different.

    I'd suggest changing them, then add a new entry for the External Web Services FQDN on the Reverse Proxy, and make sure the ports are correct.

    Also, in one of your posts you mentioned that the SfB Front End Servers are able to talk to the External Edge.  This shouldn't be the case, they only need to be able to talk to the Internal Edge.

    Monday, October 1, 2018 10:42 AM
  • Hi,

    thanks a lot. My issue is resolved.

    The issue was my reverse proxy configuration.

    Indeed, the reverse proxy was redirected to the backend on the port 443 instead of the port 4443.

    Thanks a lot once.

    Regards,

    Monday, October 1, 2018 3:21 PM
  • Thanks for your sharing, please mark you reply as answer, it will help others who have similar issue.

    Best Regards,
    Leon Lu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, October 2, 2018 8:19 AM