| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Thank you for your answer :D, however I would like to ask another question
If we're going to connect to an Access Edge Server (not the frontend) The reSIProcate stack is successfully establishing a TLS connection with the Lync Access Edge Server. However when it sends its first REGISTER message, which is 826 bytes in size, the Access Edge server thinks it contains zero bytes and drops it. The reSIProcate stack sends a retry REGISTER message at a later point of time, but not until the Lync server times out the TLS connection after 32 seconds of inactivity and closes it. Does anyone have any idea why the Lync Access Edge thinks the 826 bytes packet containg the REGISTER message is empty? Here is the server application log [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 41 | Creating TLS connection for domain sip.xxxxxxxx.xxxxxxxx.com:443 [ V4 192.168.239.232:443 TLS target domain=sip.xxxxxxxx.xxxxxxxx.com mFlowKey=0 ] on 1016 [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 183 | TLS handshake starting (client mode) [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 188 | TLS connected [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 271 | TLS connected [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 626 | TLS sessions set up with TLSv1 TLSv1/SSLv3 AES128-SHA [INFO]RESIP:TRANSPORT | SipGw | TlsConnection.cxx 315 | TLS handshake done for peer sip.xxxxxxxx.xxxxxxxx.com (2011-06-27T11:31:51.687) [INFO]RESIP:DUM | SipGw | DialogUsageManager.cxx 1341 | Got: SipResp: 408 tid=721c775895613e7e cseq=REGISTER / 1 from(wire) [ERRO][sip:lync.01@.xxxxxxxx.xxxxxxxx.com] register failed: ecode (408) edesc (Request Timeout) (2011-06-27T11:32:23.859) [INFO],RESIP:DUM | SipGw | DialogUsageManager.cxx 250 | force shutdown [INFO]RESIP:DUM | SipGw | DialogUsageManager.cxx 214 | DialogUsageManager::onAllHandlesDestroyed: removing TU [INFO]RESIP:TRANSACTION | SipGw | TuSelector.cxx 40 | TransactionUserMessage::RemoveTransactionUser TU: DialogUsageManager size=0 [INFO]RESIP:DUM | SipGw | DialogUsageManager.cxx 1149 | TU unregistered Here is an Access Edge log TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.194.000029a1 (SIPStack,CSocketContext::CSocketContext:SocketContext.cpp(134))( 0000000002F91250 ) New socket will have the same network type as its listening address socket: [EDGE_TYPE_EXTERNAL] TL_INFO(TF_CONNECTION) [0]0C30.1328::06/24/2011-07:32:30.194.000029a2 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(164))$$begin_record LogType: connection Severity: information Text: TLS negotiation started Local-IP: 192.168.239.232:443 Peer-IP: 10.42.60.31:1468 Connection-ID: 0x37A00 Transport: TLS $$end_record
TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.196.000029a3 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000002EA6650 ) Received 100 bytes TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.196.000029a4 (SIPStack,CTLSLogic::AdvanceInboundTlsHlp:tlslogic.cpp(745))[0]( 0000000002F92278 ) AcceptSecurityContext returned HRESULT=80090312 TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.196.000029a5 (SIPStack,CTCPSocket::Send:TCPSocket.cpp(1429))[0]( 0000000002F91EF0 ) WSASend 00000000015F9AB0 completed non-blocking. Bytes sent: 1465 TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.200.000029a6 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000002EA6650 ) Received 326 bytes TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.204.000029a7 (SIPStack,CTLSLogic::AdvanceInboundTlsHlp:tlslogic.cpp(745))[0]( 0000000002F92278 ) AcceptSecurityContext returned S_OK TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.204.000029a8 (SIPStack,CTCPSocket::Send:TCPSocket.cpp(1429))[0]( 0000000002F91EF0 ) WSASend 00000000015F9AB0 completed non-blocking. Bytes sent: 59 TL_INFO(TF_NETWORK) [0]0C30.1328::06/24/2011-07:32:30.214.000029a9 (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000002EA6650 ) Received 826 bytes TL_WARN(TF_COMPONENT) [0]0C30.1328::06/24/2011-07:32:30.214.000029aa (SIPStack,CBufferChain::Decrypt:BufferChain.cpp(3338))( 0000000002F8C350 ) Successfully decrypted a TLS packet containing zero bytes Returned S_FALSE <32 Seconds pass> TL_INFO(TF_NETWORK) [0]0C30.16D8::06/24/2011-07:33:02.585.000029ab (SIPStack,CRecvContext::ProcessCompletion:RecvContext.cpp(155))( 0000000002EA6650 ) Received 826 bytes TL_INFO(TF_COMPONENT) [0]0C30.16D8::06/24/2011-07:33:02.585.000029acKind Regards Surasak. Date: Fri, 24 Jun 2011 10:40:56 -0400 Subject: Re: [reSIProcate-users] reSIProcate with Lync From: sgodin@xxxxxxxxxxxxxxx To: lancelot_derluke@xxxxxxxxxxx CC: resiprocate-users@xxxxxxxxxxxxxxx If you trying to connect directly the LCS/OCS/Lync frontend server, then you are in for a world of hurt. There are many SIP extensions used in these products that make communicating with their core a very difficult exercise (ie. NTLM authentication, mandatory header requirements, etc.). It is possible with resiprocate, however you will need to make some modifications to the core stack to support everything. Here are the Lync SIP Procotol specs to give you an idea: Microsoft has created a Mediation Server to mediate between full standards based SIP to OCS/Lync flavoured SIP - however this server is only for audio calls. If you need audio calling only this is definitely the way to go.
If you really want to communicate directly to the OCS/Lync core then I would recommend looking at using Microsoft's UCMA API: http://msdn.microsoft.com/en-us/library/gg421023.aspx
Scott 2011/6/24 surasak sermluxananon <lancelot_derluke@xxxxxxxxxxx>
|