« Back to Cisco JTAPI Questions

Call drop while trying to start recording

Combination View Flat View Tree View
Threads [ Previous | Next ]
toggle
Call drop while trying to start recording
Answer
5/23/12 3:56 AM
Hi!
 
We have a phone that configured for spanless recording. When it make call to some destination, this call failed with CiscoCause CAUSE_INCOMPATABLEDDESTINATION. This happens before recording started and exactly after called abonent establish connection. I have read about this cause but do not understand what is "low layer compatibility".
 
There is a call events (3413 - called address, 4250 - calling address, 4250 address configured for recording):
 


19:48:03,795  ConnInProgressEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL
19:48:03,795  CallCtlConnOfferedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL
19:48:04,007  ConnConnectedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL
19:48:04,007  CallCtlConnNetworkReachedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL
19:48:04,007  CallCtlConnNetworkAlertingEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL


19:48:05,953  CallCtlConnEstablishedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_NOERROR, FeatureReason = REASON_NORMAL


19:48:07,008  ConnFailedEvImpl (CID=33665467, CRID=42108649, DN=4250, CHash=21589591),
CiscoCause = CAUSE_INCOMPATABLEDDESTINATION, FeatureReason = REASON_NORMAL
19:48:07,008  CallCtlConnFailedEvImpl (CID=33665467, CRID=42108649, DN=4250, CHash=21589591),
CiscoCause = CAUSE_INCOMPATABLEDDESTINATION, FeatureReason = REASON_NORMAL
19:48:07,008  ConnDisconnectedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_INCOMPATABLEDDESTINATION, FeatureReason = REASON_NORMAL
19:48:07,008  CallCtlConnDisconnectedEvImpl (CID=33665467, CRID=0, DN=3413, CHash=14627758),
CiscoCause = CAUSE_INCOMPATABLEDDESTINATION, FeatureReason = REASON_NORMAL






If we disabling phone recording at this phone line than calls successfully established at this destination.
Spanless recorder do not receive any mesages about failed call.
Flag

RE: Call drop while trying to start recording
Answer
5/23/12 7:22 AM as a reply to Sergei Gorbunov.
Hi,


When start recording it give us two streams, redirect both stream on any number but check the partition and css of phone and give the same partion and css to the recording profile.



Thanks & Best Regards
Vinay
Flag

RE: Call drop while trying to start recording
Answer
5/24/12 4:29 AM as a reply to javavinay88 (simulated).
I thought that CAUSE_INCOMPATABLEDDESTINATION is something about compatibility between calling and called sides. I can check about CSSes of phone and recording profile but i don't understand what destinations must be reachable for recording profile. Is recording profile must be able to reach called party? What problem axactly in this case?
Flag

RE: Call drop while trying to start recording
Answer
5/30/12 5:34 AM as a reply to Sergei Gorbunov.
Update!
 
There is a recorder SIP conversation with CUCM (for nearend only because farend conversation is identical to nearend conversation). CUCM must return empty ACK if it do not like any codec or ACK with one selected codec, but it return SDP witn "inactive" flag. What happens? I dont know...
 
INVITE sip:8887@10.0.129.15:5060 SIP/2.0
Date: Wed, 18 Apr 2012 15:48:28 GMT
Call-Info: <sip:10.0.120.11:5060>;method="NOTIFY;Event=telephone-event;Duration=500"
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY
From: "Dotsenko A.V." <sip:8887@10.0.120.11;x-nearend;x-refci=42108649;x-nearenddevice=SEP108CCFE16EC0>;tag=67cdf51f-dc01-45cf-820c-cd05796bb142-42108654
Allow-Events: presence,kpml
Supported: timer,resource-priority,replaces,X-cisco-srtp-fallback,Geolocation
Min-SE: 1800
Remote-Party-ID: "Dotsenko A.V." <sip:8887@10.0.120.11>;party=calling;screen=no;privacy=off
User-Agent: Cisco-CUCM7.1
To: <sip:8887@10.0.129.15>
Contact: <sip:8887@10.0.120.11:5060;transport=tcp>;isfocus
Expires: 180
Call-ID: ef72f380-f8e1e24c-1122-b78000a@10.0.120.11
Via: SIP/2.0/TCP 10.0.120.11:5060;branch=z9hG4bK1c785b97bcc9;rport=54868
CSeq: 101 INVITE
P-Preferred-Identity: "Dotsenko A.V." <sip:8887@10.0.120.11>
Session-Expires: 1800
Max-Forwards: 70
Content-Length: 0
 
SIP/2.0 200 OK
To: <sip:8887@10.0.129.15>;tag=93a38e63
Via: SIP/2.0/TCP 10.0.120.11:5060;branch=z9hG4bK1c785b97bcc9;rport=54868
CSeq: 101 INVITE
Call-ID: ef72f380-f8e1e24c-1122-b78000a@10.0.120.11
From: "Dotsenko A.V." <sip:8887@10.0.120.11;x-nearend;x-refci=42108649;x-nearenddevice=SEP108CCFE16EC0>;tag=67cdf51f-dc01-45cf-820c-cd05796bb142-42108654
Content-Type: application/sdp
Contact: <sip:8887@10.0.129.15>;expires=0
Allow: INVITE,OPTIONS,INFO,BYE,CANCEL,ACK,PRACK,UPDATE,REFER,SUBSCRIBE,NOTIFY,PUBLISH
User-Agent: SIP/1.0.1
Content-Length: 280
 
v=0
o=_Recorder 2000 1 IN IP4 10.0.129.15
s=SIP Call
c=IN IP4 10.0.129.15
t=0 0
m=audio 1026 RTP/AVP 0 9 18 101
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
 
ACK sip:8887@10.0.129.15:5060 SIP/2.0
Date: Wed, 18 Apr 2012 15:48:28 GMT
From: "Dotsenko A.V." <sip:8887@10.0.120.11;x-nearend;x-refci=42108649;x-nearenddevice=SEP108CCFE16EC0>;tag=67cdf51f-dc01-45cf-820c-cd05796bb142-42108654
Allow-Events: presence,kpml
To: <sip:8887@10.0.129.15>;tag=93a38e63
Content-Type: application/sdp
Call-ID: ef72f380-f8e1e24c-1122-b78000a@10.0.120.11
Via: SIP/2.0/UDP 10.0.120.11:5060;branch=z9hG4bK1c7a16f4bb89
CSeq: 101 ACK
Max-Forwards: 70
Content-Length: 295
 
v=0
o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.0.120.11
s=SIP Call
c=IN IP4 10.0.129.15
t=0 0
m=audio 1026 RTP/AVP 9 0 18 101
a=rtpmap:9 G722/8000
a=ptime:20
a=rtpmap:0 PCMU/8000
a=ptime:20
a=rtpmap:18 G729/8000
a=ptime:20
a=inactive
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
 
BYE sip:8887@10.0.129.15:5060 SIP/2.0
Date: Wed, 18 Apr 2012 15:48:28 GMT
From: "Dotsenko A.V." <sip:8887@10.0.120.11;x-nearend;x-refci=42108649;x-nearenddevice=SEP108CCFE16EC0>;tag=67cdf51f-dc01-45cf-820c-cd05796bb142-42108654
User-Agent: Cisco-CUCM7.1
To: <sip:8887@10.0.129.15>;tag=93a38e63
Call-ID: ef72f380-f8e1e24c-1122-b78000a@10.0.120.11
Via: SIP/2.0/UDP 10.0.120.11:5060;branch=z9hG4bK1c7c6fca1c95
P-Preferred-Identity: "Dotsenko A.V." <sip:8887@10.0.120.11>
CSeq: 102 BYE
Max-Forwards: 70
Content-Length: 0
Flag

RE: Call drop while trying to start recording
Answer
9/4/12 9:20 PM as a reply to Sergei Gorbunov.
As each call (separate calls for ear and mouth audio) will only have audio streaming toward the recorder - no return stream is expected or allowed - UCM sends a=inactive as the codec for RTP from the recorder to UCM.

See '5.1 Unicast Streams' in RFC 3264

http://www.ietf.org/rfc/rfc3264.txt
Flag

RE: Call drop while trying to start recording
Answer
9/6/12 5:37 AM as a reply to Sergei Gorbunov.
Found a problem. There is a stand: 
 
1. Cisco phone with address 4253 connected to CUCM.
2. CUCM has a H323 trunk connected to Alcatel station.
3. Phone with address 3404 connected to Alcatel station.
 
There is a pcap attached for two 4253 - 3404 calls. In first call phone 4253 configured for spanless recording and call dropped with incompatible destination. In second call spanless recording disabled and call succeeded. There is a one difference between this two calls - when call recording enabled CUCM tryed to establish a TCS two times and not succeded in second time. And i do not understand who is guilty CUCM or Alcatel.
Attachments:
Flag

RE: Call drop while trying to start recording
Answer
9/6/12 10:34 PM as a reply to Sergei Gorbunov.
It will probably take some detailed log analysis to find out the root cause here.  Certainly if you can simplify the scenario (e.g. take out the trunk/external device and use another IP phone) you can at least know that the recorder is performing OK.  My rough guess is that some sort of 'bear mode/capability' negotiation is failing, but not sure why this would appear only when recording is enabled.
 
If you need to pursue further, I would suggest opening a CDN Developer Support case (requires subscriptionemoticon
 
http://developer.cisco.com/web/devservices/alldevs#case
Flag

RE: Call drop while trying to start recording
Answer
9/7/12 8:21 AM as a reply to David Staudt.
Thanks, I think that Alcatel is produced wrong packets, because same configuration with Siemens station works. But it will be very helpful if you review logs that i send and tell me where is the problem. And maybe you will be intrested in this case to make some fixes in future releases for Alcatel compatibility.
Flag

RE: Call drop while trying to start recording
Answer
9/7/12 5:32 PM as a reply to Sergei Gorbunov.
For investigating UCM MGCP/H.323 interop with Alcatel, you will need to work with regular Cisco TAC.
Flag