Hi,
 
we access the uaCSTA interface of the CME system to do call monitoring and call control. While placing a call every now and then the CME accepts the MakeCall request but does not handle it. In basic words: MakeCallRequest is sent, MakeCallResponse is received containing a valid call ID. Afterwards the CME sends a OriginatedEvent telling the device which should handle the call is in dialtone mode and nothing else happens. I can clear the connection using the CSTA interface.
 
This scenario happens a lot in customer systems, obviously not in the dev system in house.
 
Traces:
 
################################################################################

20.06.2011 11:05:46:718;32;SIP;TRANSACTION COMPLETED: ID=z9hG4bK42D851F53 SEQUENCE=241 METHOD=INFO DIRECTION=CALLEE

20.06.2011 11:06:05:626;32;SIP;TRANSACTION STARTED:
ID=z9hG4bK.A5B4B925D8AA4E9044EEE7802FC785A4 SEQUENCE=280 METHOD=INFO
DIRECTION=CALLER

20.06.2011 11:06:05:626;32;SIP;<--- REQUEST FROM 192.168.224.2:5360 TO 192.168.224.1:5060

################################################################################

INFO sip:291@192.168.224.1:5060;transport=tcp SIP/2.0

Via: SIP/2.0/tcp 192.168.224.2:5360;branch=z9hG4bK.A5B4B925D8AA4E9044EEE7802FC785A4

From: <sip:ecsta@bekodkt-bbt013.beko.local>;tag=03CCACE3AA60452A135F268A5314B7F3

To: <sip:291@192.168.224.1>;tag=F542FA70-E3D

Call-ID: 4E5B1E8ED943431499EAB2930082BFC0

CSeq: 280 INFO

Content-Type: application/csta+xml

Content-Disposition: signal;handling=required

Max-Forwards: 70

User-Agent: ESTOS ECSTA

Content-Length: 291
<?xml version="1.0" encoding="UTF-8"?><MakeCall
xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3"><callingDevice>tel:291;device=0002FDFFD0EE</callingDevice><calledDirectoryNumber>tel:00815136856177</calledDirectoryNumber><autoOriginate>doNotPrompt</autoOriginate></MakeCall>
################################################################################

20.06.2011 11:06:05:641;32;SIP;---> RESPONSE FROM 192.168.224.1:5060 TO 192.168.224.2:5360

################################################################################

SIP/2.0 100 Trying

Via: SIP/2.0/tcp 192.168.224.2:5360;branch=z9hG4bK.A5B4B925D8AA4E9044EEE7802FC785A4

From: <sip:ecsta@bekodkt-bbt013.beko.local>;tag=03CCACE3AA60452A135F268A5314B7F3

To: <sip:291@192.168.224.1>;tag=F542FA70-E3D

Date: Mon, 20 Jun 2011 09:02:48 GMT

Call-ID: 4E5B1E8ED943431499EAB2930082BFC0

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 280 INFO

Content-Length: 0
################################################################################

20.06.2011 11:06:05:641;32;SIP;---> RESPONSE FROM 192.168.224.1:5060 TO 192.168.224.2:5360

################################################################################

SIP/2.0 200 OK

Via: SIP/2.0/tcp 192.168.224.2:5360;branch=z9hG4bK.A5B4B925D8AA4E9044EEE7802FC785A4

From: <sip:ecsta@bekodkt-bbt013.beko.local>;tag=03CCACE3AA60452A135F268A5314B7F3

To: <sip:291@192.168.224.1>;tag=F542FA70-E3D

Date: Mon, 20 Jun 2011 09:02:48 GMT

Call-ID: 4E5B1E8ED943431499EAB2930082BFC0

Server: Cisco-SIPGateway/IOS-12.x

CSeq: 280 INFO

Contact: <sip:291@192.168.224.1:5060;transport=tcp>

Content-Type: application/csta+xml

Content-Disposition: signal;handling=required

Content-Length: 280
<?xml version="1.0" encoding="UTF-8"?>

<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">

<callingDevice>

<callID>E7713CC7-9A5211E0-803AAA46-70FAE5AE</callID>

<deviceID>tel:291;device=0002FDFFD0EE</deviceID></callingDevice></MakeCallResponse>


################################################################################

20.06.2011 11:06:05:641;32;SIP;TRANSACTION COMPLETED:
ID=z9hG4bK.A5B4B925D8AA4E9044EEE7802FC785A4 SEQUENCE=280 METHOD=INFO
DIRECTION=CALLER

20.06.2011 11:06:05:641;32;SIP;---> REQUEST FROM 192.168.224.1:16778 TO 192.168.224.2:5360

################################################################################

INFO sip:ecsta@192.168.224.2:5360;maddr=192.168.224.2;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 192.168.224.1:5060;branch=z9hG4bK42D8618A

From: <sip:291@192.168.224.1>;tag=F542FA70-E3D

To: <sip:ecsta@bekodkt-bbt013.beko.local>;tag=03CCACE3AA60452A135F268A5314B7F3

Date: Mon, 20 Jun 2011 09:02:48 GMT

Call-ID: 4E5B1E8ED943431499EAB2930082BFC0

User-Agent: Cisco-SIPGateway/IOS-12.x

Max-Forwards: 70

Timestamp: 1308560568

CSeq: 161 INFO

Contact: <sip:291@192.168.224.1:5060;transport=tcp>

Content-Type: application/csta+xml

Content-Disposition: signal;handling=required

Content-Length: 554
<?xml version="1.0" encoding="UTF-8"?>

<OriginatedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">

<monitorCrossRefID>000154AF</monitorCrossRefID>

<originatedConnection>

<callID>E7713CC7-9A5211E0-803AAA46-70FAE5AE</callID>

<deviceID>tel:291;device=0002FDFFD0EE</deviceID></originatedConnection>

<callingDevice>

<deviceIdentifier>tel:291;device=0002FDFFD0EE</deviceIdentifier></callingDevice>

<calledDevice>

<notKnown/></calledDevice>

<localConnectionInfo>connected</localConnectionInfo>

<cause>normal</cause></OriginatedEvent>
 
From the client side everything looks okay....
 


 
 
 
 
 
 
 
 
 
 
 

Hi Raghavendra,
 
from the CSTA view i do not receive any more events. The system stays in that status until i hang up the phone manually or drop the connection using
ClearConnection. As i cannot reproduce the scenario in house i cannot attach any more logging apart from the uaCSTA payload i´m logging anyhow. As mentioned we´ve seen this issue in about a dozen customer scenarios and the customers are getting bugged. Every log i´m looking at looks exactly the same. MakeCall MakeCallResult Originated nothing. It does not depend wether i call an internal extension or a external destination.
 
The CME does NOT process the MakeCall request as supposed to.
 
Jan
 
 
 
 
 
 

Hi Raghavendra,



i received logs from a customer who is facing the issue described above. MakeCall, MakeCallResponse, Originated, no more events, Phone stays in dialtone mode.


Hope someone can take a deeper look in whats going on as from the uaCSTA part everything looks fine.


Jan

 
 

Attachments:

Hi Raghavendra,
 
i´m using the CSTA TR87 interface which is part of the UC Express Services Interface. I´m not sure what UCXSI API is in your terminology but from my point of view i´m not in the wrong forum...
 
Jan

Hi,

I am having a very similar problem here. Except that i receive the following CSTA message if i do not clear the connection after a few seconds.

<?xml version="1.0" encoding="UTF-8"?>
<ConnectionClearedEvent xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<monitorCrossRefID>00000A32</monitorCrossRefID>
<droppedConnection>
<callID>2344282E-EAAD11E0-8C37B813-25886C02</callID>
<deviceID>tel:221;device=B8BEBF9D46C7</deviceID></droppedConnection>
<releasingDevice>
<deviceIdentifier>tel:221;device=B8BEBF9D46C7</deviceIdentifier></releasingDevice>
<cause>destNotObtainable</cause></ConnectionClearedEvent>

This seams to indicate that the extension number is not valid however, it can be reached by the cisci ip phone with the 221 extension.

Any ideas on what could cause this problem?

P.S. I am not using the UCXSI SDK but i could not find a more appropriate forum. Could you point it to me if there is one?