Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

Lync Edge Server FQDN and IP PORTS

(Version 1.2, Update 26.11.2014)

As we all know, we can configure Lync Edge Server in several way.

1) Single Edge Server with a SINGLE IP ADDRESS
2) Single Edge Server with MULTIPLE IP ADDRESSES (3x IPs)
3) Multiple Edge Server in a Pool, with MULTIPLE IP ADDRESSES (Zx 3 IPs)

Regardless what we are going to configure, there are common / well-known TCP Port necessary making Lync work, which are:

Access:
Port: 443 and 5061

Conferencing:
Port: 443 and (444)

AV:
Port: 443

(I have not listed other ports, e.g. STUN or the dynamic port range. This is not required for the topic discussed here)

External FQDN with single IP address:

What can we see here? If we are going to choose a single IP address, we would have TCP Port overlapping. Therefore the only way avoiding this is assigning other ports.
Additionally we will also see and are reminded that Lync highly depends on DNS. If we have single IP, we must have use single, unique FQDN for all services.

E.g.:
ACCESS:
SIP.CUSTOMER.COM PORT:5061

CONFERENCING:
SIP.CUSTOMER.COM PORT:444

AV:
SIP.CUSTOMER.COM PORT:443


Note:
The TCP Port 444 is only a recommendation by Microsoft. You can make use of any other TCP, e.g. 4343 or 1234.

External FQDN with multiple IP addresses:

In comparison, if we are choosing to make use of three individual IP addresses. We also need three different FQDN, one for each service.

ACCESS:
SIP.CUSTOMER.COM PORT:443
 
CONFERENCING:
CONF.CUSTOMER.COM PORT:443
 
AV:
AV.CUSTOMER.COM PORT:443


If we now compare with the Microsoft provided illustration of the Edge Server related Enterprise Perimeter Network. This TCP Port named here are for INCOMING CONNECTIONS ONLY.
Now it becomes more clearer what the requirements are if a outside Lync user needs a connection to the published services.

The most common used server are:
IM, Audio/Video, Desktop or App Sharing, as well as Presence Queries.
Regardless which configuration was chosen, the single IP or triple IP configuration. Those service are all addressed via the common port of 443 and 5061. So we can assume, those service are mostly working independently of the chosen configuration model.

Web Conferencing Service:

Now we need having a look into the Lync Web Conferencing Service, publish via the Edge Server. Right, we looked at the incoming IP connection and here is a different.
If you really configure Best-Practice and user three (3) public IP addresses, everything is going to be fine. No one should experience any issues. This is due to the connection made to e.g. conf.customer.com and it's common TCP Port 443 as incoming.
And this ports are always activated on every Firewall or via any Reverse Proxy.

But what happened if we are using the single IP address with single FQDN?
Sure, as you can see in the config example, we must use another TCP Port rather than 443.
As per default, Microsoft suggests TCP Port 444.

But regardless of this, what ever port we are going to chose, mostly the outgoing Firewalls are not open for any for those other TCP Ports. (Seen from the prospective of a meeting participant)

This clearly means, you will experience issues with a lot of your Federation Partners and meeting participants!

NOTE:
Beware of the negative impact if you decide going for a SINGLE PUBLIC IP ADDRESS. I do NOT recommend this configuration.


Having a look into the Protocol:

Beside the trace, this is also very nice example of how the Edge service is acting as a Application Proxy, you see how the Edge receiver an internal message, will do  the processing and than only it will send the message on behalf out to the internet.
I traced a problematic single IP configuration from outgoing point of view:
This is the Edge Server:

The customer clicked an MEETING INVITE in Outlook, the Web Browser opened and was issuing the conference back to the Lync Desktop Client.

- invited user is identified as nils.caller@correct.com (aka CALLER participant at this meeting)
- internal network is 10.10.x.y with an AD FQDN INTERNAL.AD
- meeting initiator is false@singlip.com and meeting ID is V3JZ92CZ (aka  ORGANIZER)
- external single IP 99.79.91.241

 
Edge intern NIC incoming from caller -> organizer INVITE
the Edge should initiate the outgoing meeting, seen in the message-body. the conferencing service should add an used (caller) to the meeitng
TL_INFO(TF_PROTOCOL) [0]097C.0834::07/11/2014-11:15:26.143.0000003d (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DB
Direction: incoming;source="internal edge";destination="external edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: request
Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Contact: <sip:nils.Caller@correct.com;opaque=user:epid:6Ng_wBKilFeryhezW1lEuAAA;gruu>
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Record-Route: <sip:LYNCFEPOOL01.INTERNAL.AD:5061;transport=tls;ms-fe=LYNCFRCLSERV01.INTERNAL.AD;opaque=state:T;lr>;tag=0CF71FDEF89C166BEDCEB50B598409B1
Max-Forwards: 69
Content-Length: 1018
Content-Type: application/cccp+xml
Message-Body:


- <request xmlns="urn:ietf:params:xml:ns:cccp"
mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
C3PVersion="1"
to="sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ"
from="sip:nils.Caller@correct.com"
requestId="344391952">
+ <addUser>
</request>


 
Next the domain discovery done by the Edge Server and finding the FQDN and IP
TL_INFO(TF_CONNECTION) [3]097C.02C0::07/11/2014-11:15:26.174.000001eb (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(454))[3899431948] $$begin_recordSeverity: information
Text: TLS negotiation started
Local-IP: 10.11.10.84:61621
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Connection-ID: 0x49E800
Transport: M-TLS


 
Here the TLS negotiation INFO message is generated.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.252.00000286 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[1802118479] $$begin_recordSeverity: information
Text: Routed a locally generated request
SIP-Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
SIP-Call-ID: 38AA2A4D958FC58A1F97
SIP-CSeq: 1 NEGOTIATE
Peer: sip.singleip.com:5061


 
The Edge Server send the negotiate message the meeting org.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.252.00000292 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[1802118479] $$begin_recordTrace-Correlation-Id: 1802118479
Instance-Id: BF9DC
Direction: outgoing;source="local";destination="external edge"
Peer: sip.singleip.com:5061
Message-Type: request
Start-Line: NEGOTIATE sip:127.0.0.1:5061 SIP/2.0
From: sip:SIP.CORRECT.COM;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
To: sip:sip.singleip.com
Call-ID: 38AA2A4D958FC58A1F97
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bKD7CAB5A3.FA2521EF7066539E;branched=FALSE
Max-Forwards: 0
Content-Length: 0
Compression: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,IPv6,TlsRecordSplit
Server: RTC/5.0


 
We now receive the SIP 200/OK message based in the INVITE, so the ACCESS Edge at the caller site is working.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.283.000002bf (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3194725999] $$begin_recordTrace-Correlation-Id: 3194725999
Instance-Id: BF9DD
Direction: incoming;source="external edge";destination="internal edge"
Peer: sip.singleip.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: sip:SIP.CORRECT.COM;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
To: sip:sip.singleip.com;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 38AA2A4D958FC58A1F97
CSeq: 1 NEGOTIATE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bKD7CAB5A3.FA2521EF7066539E;branched=FALSE;received=80.157.6.163;ms-received-port=61621;ms-received-cid=D5BD000
Content-Length: 0
Compression: LZ77-64K
Supported: NewNegotiate,OCSNative,ECC,TlsRecordSplit
Server: RTC/4.0



Edge as Application Proxy must process several Information, here connection is established with the organizer site
TL_INFO(TF_CONNECTION) [0]097C.0C74::07/11/2014-11:15:26.283.000002da (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(383))[3899431948] $$begin_recordSeverity: information
Text: Connection established
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Transport: M-TLS
Data: alertable="no"


 
Now the Edge has processed even more and also agreed the sip.singleip.com domain, its certificate and established TLS connection
TL_INFO(TF_CONNECTION) [0]097C.0C74::07/11/2014-11:15:26.283.0000030a (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(383))[3899431948] $$begin_recordSeverity: information
Text: SIP message traffic has established the peer server as a Discovered Domain federated peer
Peer-IP: 99.79.91.241:5061
Peer: sip.singleip.com:5061
Transport: M-TLS


 
Edge internal process info for send INVITE from intern site (caller), domain is now in the discovered domain list
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.283.00000310 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061
Data: domain="singleip.com"


 
Edge is now preparing for sending the INVITE to the external organizer
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.283.0000036b (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: Routed a request to a Discovered Domain federated peer
SIP-Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061



Here it comes:
Edge has now proxied the internal caller sending request he would like to join the external meeting. therefore the caller request is send finally to the external site (singleip.com) 
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.283.00000377 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DB
Direction: outgoing;source="internal edge";destination="external edge"
Peer: sip.singleip.com:5061
Message-Type: request
Start-Line: INVITE sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Contact: <sip:nils.Caller@correct.com;opaque=user:epid:6Ng_wBKilFeryhezW1lEuAAA;gruu>
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE;ms-internal-info="aqgQ48dd2SfNMeRfbruAAZXq8dFFBTtKluOHag-KpPn1wHawNkNq4BswAA"
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Record-Route: <sip:SIP.CORRECT.COM:5061;transport=tls;epid=f5710ea2b3;lr;ms-key-info=AAEAAdJOgwIBMa2t5ZzPASlkLxWClArLg5fYAz5vMU1--3qvyX7XKhdANCiKC-GE07tJz6E3DmxM-Uo1JCVXZwiNF0uZ2ZM-MBkpzf8q70BVHpEeVVJxW4-ptvp1zWHfjfpaL75-G59cC8TTOSXREQP7w4wTVzV730yNT9Ph48zRr2YVibOrM1R1QJThh3fhOMGY6BjkBdw1rGGmlgbssXVOjCAu7Q9vs3VwxSIOqB6A1VbZNUG8zoAjDaqm_FdS6cziurxnJSAl9at4yVYFUS7LIzHbhMal7Clz5WDPENfDR-6YkottO4A0_I4ocqv3P6k_txrZumb8uB5Gf0pnwjZuwy2boSzwgo2aVu-OrvBcaL9IIlRA0kMgZs62YXBCUVl_F7KRJ9cSUpgbN-B5pMVtPhU7nlCZluxkqB-db2B149xOw4aQ4Eyso3c7gRntFMq61dfI3kPyPFDgNdpDtNmgWwcvEBXFCK2l8EGSHElRsNSIyE-D1UgGQBieo3bPW41uxGIXJfndV9nAMQlbB6mqR-UEbwNGyCgX_cbdHEdPQbClzoqvQFDZ9D857BWNaTBAYfVtbstvrVLsx5vvjAuFY_zFDtNjwKZtYkKJRnedDYnv0kJbBK7pu3bw3LQ0WruFFS-shxBWC9mrUSrhFggcQIoolloakvT0bXL4tHdggWb9fsSSUrCMCQm4KSQC;ms-route-sig=dtgD9HmH2Ck2pYUw_OaiCBzENJLtQyjLBgVnOdt26vsAoHawNkjqWm6wAA>;ms-rrsig=dtATEXIj4kuWMVvcXWz8MoMCB3C4BfDk6UfICkkpSjpRMHawNkjqWm6wAA;tag=6AA3DC66E3BF1C9E7EFA44888B1B7E51
Record-Route: <sip:LYNCFEPOOL01.INTERNAL.AD:5061;transport=tls;ms-fe=LYNCFRCLSERV01.INTERNAL.AD;opaque=state:T;lr>;tag=0CF71FDEF89C166BEDCEB50B598409B1
Max-Forwards: 68
Content-Length: 1018
Content-Type: application/cccp+xml
Message-Body:


- <request xmlns="urn:ietf:params:xml:ns:cccp"
mscp="http://schemas.microsoft.com/rtc/2005/08/cccpextensions"
C3PVersion="1"
to="sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ"
from="sip:nils.Caller@correct.com"
requestId="344391952">
+ <addUser>
</request>


 

Immediately after the INVITE was send, the SIP 404 Not Found was received. How this can be happened? 
The Web Conferencing Server is awaiting incoming request on TCP Port 444, This is REQUEST is coming directly from the initiating client. The local PC's Lync Client. 
The TCP Port 444 is blocked and the opposite Edge Server now send the INFO that a client did not send a request, meaning he did not receive any request matching on Port 444. (You would see this message, if you run a WireShark on our Web Traffic)
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.000003b3 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DE
Direction: incoming;source="external edge";destination="internal edge"
Peer: sip.singleip.com:5061
Message-Type: response
Start-Line:
SIP/2.0 404 Not Found
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE;ms-internal-info="aqgQ48dd2SfNMeRfbruAAZXq8dFFBTtKluOHag-KpPn1wHawNkNq4BswAA";received=80.157.6.163;ms-received-port=61621;ms-received-cid=D5BD000
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Content-Length: 0



Two more processing infos regading the SIP domain. 
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.0000040f (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line:
SIP/2.0 404 Not Found
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: sip.singleip.com:5061
Data: domain="singleip.com"
 

 
Preparing the SIP 404 message being send to the internal Lync Frontend.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.000004c3 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[2376455152] $$begin_recordSeverity: information
Text: Response successfully routed
SIP-Start-Line: SIP/2.0 404 Not Found
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 INVITE
Peer: LYNCFEPOOL01.INTERNAL.AD:51714


  
the proxied message is now send to the internal Frontend.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.000004cf (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[2376455152] $$begin_recordTrace-Correlation-Id: 2376455152
Instance-Id: BF9DE
Direction: outgoing;source="external edge";destination="internal edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: response
Start-Line: SIP/2.0 404 Not Found
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 INVITE
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Via: SIP/2.0/TLS 10.10.45.69:49360;ms-received-port=49360;ms-received-cid=2E9D600
Content-Length: 0
ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="singleip.com";PeerServer="sip.singleip.com";source="SIP.CORRECT.COM"
ms-edge-proxy-message-trust: ms-source-type=AutoFederation;ms-ep-fqdn=EDGEPOOL01.INTERNAL.AD;ms-source-verified-user=unverified;ms-source-network=federation


  
The Frontend Server informs the organize site now that the connection was failing and Edge Server starts it proxying process.
TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.00000507 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3798769121] $$begin_recordTrace-Correlation-Id: 3798769121
Instance-Id: BF9DF
Direction: incoming;source="internal edge";destination="external edge"
Peer: LYNCFEPOOL01.INTERNAL.AD:51714
Message-Type: request
Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.Caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 ACK
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE
Max-Forwards: 70
Content-Length: 0
ms-diagnostics-public: 5012;reason="ACK is being generated on receipt of a failure final response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent"


 
Processing the ACK so it can be send to the organizer
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.00000637 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[3798769121] $$begin_recordSeverity: information
Text: The message has a Discovered Domain
SIP-Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 ACK
Peer: sip.singleip.com:5061
Data: domain="singleip.com"


 
Processing and check against the discovered domain list.
TL_INFO(TF_DIAG) [0]097C.0C74::07/11/2014-11:15:26.299.00000679 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[3798769121] $$begin_recordSeverity: information
Text: Routed a request to a Discovered Domain federated peer
SIP-Start-Line: ACK sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
SIP-Call-ID: 53fa037467934a3aa58afa7da405cffd
SIP-CSeq: 1 ACK
Peer: sip.singleip.com:5061



The ACK is now send the sip.singleip.com organizer site. 

TL_INFO(TF_PROTOCOL) [0]097C.0C74::07/11/2014-11:15:26.299.00000685 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3798769121] $$begin_recordTrace-Correlation-Id: 3798769121
Instance-Id: BF9DF
Direction: outgoing;source="internal edge";destination="external edge"
Peer: sip.singleip.com:5061
Message-Type: request
Start-Line: ACK sip:fleu@fev.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ SIP/2.0
From: "Caller, Nils"<sip:nils.caller@correct.com>;tag=e4776a37ed;epid=f5710ea2b3
To: <sip:false@singleip.com;gruu;opaque=app:conf:focus:id:V3JZ92CZ>;tag=EDEE8C0427072C271B9B823E3B26BC5F
Call-ID: 53fa037467934a3aa58afa7da405cffd
CSeq: 1 ACK
Via: SIP/2.0/TLS 10.11.10.84:61621;branch=z9hG4bK1616E949.64036B07705F839E;branched=FALSE
Via: SIP/2.0/TLS 10.10.10.127:51714;branch=z9hG4bKDFE93E20.E0C27AFE227343AD;branched=FALSE;ms-received-port=51714;ms-received-cid=4B8F00
Max-Forwards: 69
Content-Length: 0
ms-diagnostics-public: 5012;reason="ACK is being generated on receipt of a failure final response for an INVITE forked by application";AppUri="http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent"


Comments

  1. Hi Thomas
    Did you find a solution of ms-diagnostics-public: 5012;reason="ACK is being generated on receipt of a failure final response for an INVITE forked by application.

    BR Henrik Börjesson

    ReplyDelete
    Replies
    1. Hi Hendrik,

      yes. This is all about the solution.
      If you are using a single IP address and have a port applied other the 443 (which you have to do with this deployment type), than there are two solutions:
      1. if its you accessing a partners meeting, just open your ports on the firewall ,mostly 444
      2. if its you hosting, change your deployment to 3 public IPs, as recommended.

      Hope this helps
      Thomas

      Delete

Post a Comment

Popular posts from this blog

How to hide users from GAL if they are AD Connect synchronized

MFA with Guest Access and different tenants settings