CCE First Call fail

[Khoon Yong Chua]

hi,

I had installed CCE 1.4.1 previously and it is working fine with SIP Trunking to PSTN, except for the below issue.  Hope someone can help or give suggestions to resolve it:

1.  After 3 hours of no call activity, I make a call from PSTN to SFB client.  The first call will fail, and subsequent calls are OK.

2.  If the first call is from SFB client to PSTN, the call is OK.

This weird behaviour is most puzzling.

Thank you.

[#2]

That is an interesting issue. I don't see that in my environment running on 1.4.1.

Could you try to test the scenario running IncomingAndOutgoingCall CLS scenario on all servers??

Start-CsCLSlogging -Scenario IncomingAndOutgoingCall

Reproduce the issue.

Stop-CsCLSLogging -Scenario IncomingAndOutgoingCall
Search-CsCLSLogging -FileName logfile.txt

Have a look at the logfile or post it in this thread.

Hope this helps you

/Kenneth ML

[#3]

Thank you Kenneth.

[#4]

Please shaare the logs. How many Cloud COnnector instances do you have?

[#5]

hi,

Currently I had deployed 1 CCE instance to a customer, and this one got no issue.

I am having the first call issue for my testbed CCE, where the first call from PSTN would fail after 3 hours of no activity.

The OK and NG trace at that moment is shown below:

OK:

TL_INFO(TF_COMPONENT) [mspool\MediationServer]0638.0324::04/24/2017-01:51:49.036.00002046 (S4,SipTlsConnection.set_DontSendNegotiateRequest:sipconnection.cs(3433)) (00000000028DE1A9)Negotiate Request = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.0324::04/24/2017-01:51:49.036.00002047 (S4,TlsTransport.set_DontSendNegotiateRequest:tlstransport.cs(110)) (0000000001973ECC)Negotiate = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.0324::04/24/2017-01:51:49.036.00002048 (S4,NegotiateLogic.set_DontSendNegotiateRequest:negotiatelogic.cs(146)) (0000000002ACFB91)Negotiate = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.0324::04/24/2017-01:51:49.037.00002049 (S4,NegotiateLogic.set_DoesSupportClientDraining:negotiatelogic.cs(165)) (0000000002ACFB91)Support Client Draining = False
TL_INFO(TF_CONNECTION) [edgepool\EdgeServer]09EC.084C::04/24/2017-01:51:51.991.00002002 (SIPStack,SIPAdminLog::WriteConnectionEvent:SIPAdminLog.cpp(388)) [1923522296] $$begin_record
Severity: information
Text: Server connection established
Peer-IP: 192.168.1.127:50521
Peer: mspool.axiomdemosite.local:50521;ms-fe=MediationServer.axiomdemosite.local
Peer-Cert: mspool.axiomdemosite.local(MediationServer.axiomdemosite.local)
Transport: M-TLS
Data: alertable="yes"
$$end_record


NG:

TL_INFO(TF_COMPONENT) [mspool\MediationServer]0638.02E4::04/25/2017-01:20:46.406.000020F9 (S4,SipTlsConnection.set_DontSendNegotiateRequest:sipconnection.cs(3433)) (000000000121AFE8)Negotiate Request = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.02E4::04/25/2017-01:20:46.406.000020FA (S4,TlsTransport.set_DontSendNegotiateRequest:tlstransport.cs(110)) (0000000001F9A42A)Negotiate = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.02E4::04/25/2017-01:20:46.406.000020FB (S4,NegotiateLogic.set_DontSendNegotiateRequest:negotiatelogic.cs(146)) (0000000002CBB96E)Negotiate = False
TL_INFO(TF_NETWORK) [mspool\MediationServer]0638.02E4::04/25/2017-01:20:46.406.000020FC (S4,NegotiateLogic.set_DoesSupportClientDraining:negotiatelogic.cs(165)) (0000000002CBB96E)Support Client Draining = False
TL_INFO(TF_PROTOCOL) [mspool\MediationServer]0638.0A78::04/25/2017-01:20:51.921.000020FD (S4,SipMessage.DataLoggingHelper:sipmessage.cs(801)) [1172392135]
<<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_10FC87D>], 192.168.1.127:5068<-192.168.1.126:35715
CANCEL sip:+6568130463@gateway1.axiomdemosite.com SIP/2.0
FROM: "96794134" <sip:+6596794134@202.163.63.213>;tag=1c1646615811
TO: <sip:+6568130463@gateway1.axiomdemosite.com>
CSEQ: 1 CANCEL
CALL-ID: 1270468232254201711120@192.168.1.126
MAX-FORWARDS: 10
VIA: SIP/2.0/TCP 192.168.1.126:5060;alias;branch=z9hG4bKac96743477
CONTENT-LENGTH: 0
USER-AGENT: Mediant SW/v.7.20A.001.501

[#6]

Hi.

<<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_10FC87D>], 192.168.1.127:5068<-192.168.1.126:35715
CANCEL sip:+6568130463@gateway1.axiomdemosite.com SIP/2.0
FROM: "96794134" <sip:+6596794134@202.163.63.213>;tag=1c1646615811
TO: <sip:+6568130463@gateway1.axiomdemosite.com>
CSEQ: 1 CANCEL
CALL-ID: 1270468232254201711120@192.168.1.126
MAX-FORWARDS: 10
VIA: SIP/2.0/TCP 192.168.1.126:5060;alias;branch=z9hG4bKac96743477
CONTENT-LENGTH: 0
USER-AGENT: Mediant SW/v.7.20A.001.501

According to this SIP message, the Audiocodes device (IP 192.168.1.126) sends the cancel to the mediation server (IP 192.168.1.127). We cannot tell from this why it does so, but maybe you can check the log in the Audicodes device or include more of the SIP logs from the beginning of the sequence starting with the invite.

/Kenneth ML