i have a CIPC 8.1.6 with CUVA 2.2 registered (SCCP) in a CUCM 8.6.2.
This CUCM 8.6.2 have a SIP trunk with a VCS X7.0.3
A C40 TC5.1.3 registered on this VCS as SIP.
The search rules are fine.
The C40 can call the CIPC+CUVA, with media routed=false on VCS (SIP-SIP call). Audio+Video OK.
But, the CIPC cannot call the C40. The VCS found the destination (need transforms) and with this match as SIP destination, the reason is cancell.
The SIPpacket debug on C40 shows:
90178.61 SipCall I: sip_call_handler::handleSIPMDiscInd(-1/0/-1): Incoming disconnect (reason: Request Terminated, sipCause.dc=7, sipCause.status=487)
90178.64 SipCall I: ==== affirmIncomingDisconnect appId=-1, stackId=0, eventCookie=-1
Is there some SIP incompatibility between those devices?
I didn't checked in such a way; however I tested with my E20 registered with CUCM8.6 as SIP and CIPC registered with CUCM as SCCP. There was no issue.
Today I will check this and let you know; however I don't think we have this problem. I would recomment to provide log using https://supportforums.cisco.com/docs/DOC-1564 Page 17.
it should work..i have seen this working in one of our customer scneario.
although software versions are not all same..But still it should have worked
just as headsup i tested the scenario with CIPC 8.6.1 and TC 5.1.3
call connects and audio works both direction but got no video!!:) but i think somehow we can fix it..and i didn't verfied the BFCP things current. however i am expecting to be enable!!
my setup involved..cucm 8.6.2, CIPC 8.6.1, VCS x7.2 (don't think ver of vcs creates any problem in your case), TC 5.1.3
Do you confirm that the call was SIP-SIP btw two devices? (in VCS - Status > Calls > Calls)
Regarding Video, double check if you have CUVA 2.2 (SCCP only) on your CIPC PC and in CUCM the CIPC Device has Video Capabilities: Enable.
I did a tcpdump on C40 and VCS at the same time.
What i found was a SIP CANCEL came in from CUCM to VCS while the C40 start to ring.
INVITE from CUCM to VCS (VCS>CUCM) - 18.296 (
VCS send the 100-trying to CUCM (VCS>CUCM) - 18.302
The INVITE goes to the C40 (VCS>C40) - 18.337
C40 send the 180-ringing to VCS (C40>VCS) - 18.542
The VCS send the Ring info to CUCM (VCS>CUCM) - 18.546
CUCM send the CANCEL to VCS (CUCM>VCS) - 18.550
VCS send the OK (VCS>CUCM) - 18.551
VCS forward the CANCEL to C40 (VCS>C40) - 18.551
C40 responds with 487 - Request Terminated (C40>VCS) - 18.725
CUCM - VCS - C40
I also did a test registering the C40 directly to CUCM as SIP (not provisioned) and then the CIPC (8.6.1) can call the C40 (TC5.1.3).
So, i don´t think there is some incompatibility btw those two. The problem seems to be btw CUCM and VCS.
El mensaje fue editado por: Elter Picolo
pull the RTMT logs this will help to diagnose the issue.
It could be related to bug on cucm for doing a DNS query for contact header present in sip messages!!can't confirm without RTMT logs.
Hi Alok, which log and/or trace can we observe this? Do you have the suspected bug id to search for?
I was looking at the real time > calllogs and shows me the same call flow.
Could you give some sample what to look for. i cannot put logs here...
HI Elter. If I were to venture out on this one, I do believe Alok is referring to CSCty07061.
If domain name is in the contact header, CUCM may do a DNS lookup of the domain name in the contact header, but it should be using the record-route header to send requests back to.
In SDI/SDL trace, you may see entries as such after 180 ringing is received:
13:28:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: Received SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^* 13:28:54.838 |//SIP/SIPDns(1,72,1)/copyRecordRspToRecordReq: Retry SRV query as an 1 query|0,0,0,0.0^*^* 13:28:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or AAAA query called as SRV query Fail):hostname=blahblahblah.com, ReqType=1,serversused=0 |0,0,0,0.0^*^* 13:28:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: Received SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^* 13:28:54.838 |//SIP/SIPDns(1,72,1)/copySdlDnsSrvRecordRspToSpi: ReqType is 1|0,0,0,0.0^*^* 13:28:54.838 |//SIP/SIPDns(1,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A Query Fail)|0,0,0,0.0^*^* 13:28:54.839 |//SIP/Stack/Info/0x0/ccsip_spi_get_msg_type returned: 2 for event 44|0,0,0,0.0^*^* 13:28:54.839 |//SIP/Stack/Error/0xf1860b0/DNS Query failed for query_type: 1|0,0,0,0.0^*^* 13:28:54.839 |//SIP/Stack/Info/0xf1860b0/Categorized cause:3, category:128|0,0,0,0.0^*^* 13:28:54.839 |//SIP/SIPHandler/ccbId=0/scbId=0/sip_stop_timer: type=SIP_TIMER_EXPIRES value=180000 retries=0|0,0,0,0.0^*^* 13:28:54.839 |//SIP/Stack/Transport/0xf1860b0/Sending CANCEL to the transport layer|0,0,0,0.0^*^*
The workaround would be to have the CUCM resolve this, and the call will process.
As pointed by Patrick you can pull the SDI/SDL traces from the CUCM. Please ensure you set the relevant log levels to detailed under call manager serviceability.!!
You will see in that CUCM is trying to do DNS srv record query for the contact header.!!!the workaround for that is to have a DNS configuration to resolve that domain.!!