Re: interoperability btw CIPC 8.6.1 and TC5.1.3?

epicolo · ‎08-15-2012

Hi,

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

Any ideas?

Is there some SIP incompatibility between those devices?

Thanks

vivsing2 · ‎08-16-2012

Hi Elter,

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.

Regards,

Vivek

Alok Jaiswal · ‎08-16-2012

Hi Elter,

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

Thanks

Alok

Alok Jaiswal · ‎08-16-2012

Elter,

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

Thanks

Alok

epicolo · ‎08-16-2012

Thanks Alok.

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.

Thanks again.

epicolo · ‎08-16-2012

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

Any tips?

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

Alok Jaiswal · ‎08-17-2012

Hi Elter,

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.

Thanks

Alok

epicolo · ‎08-17-2012

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...

Thanks

Patrick Pettit · ‎08-21-2012

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.

VR

Patrick

Alok Jaiswal · ‎08-22-2012

Hi Elter,

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.!!

Thanks

Alok