Re: Uc560 spa8000 integration

mantis · ‎07-19-2010

Hi all,

I've followed the integration pdf guide for this, and managed to get the majority of functionality woking.

This scenario is that CME and SIP will be working off the uc560.

The uc560 is running the latest software pack 8.0.2

The major issue I'm having is that if there is an active call between 2 analogue extensions off the spa8000 and this call is then transferred to a IP phone running either SCCP/SPCP (7941/SPA504G) the transfer completes, and the call is answered by the ip phone, however 1 way audio occurs (IP Phone cant' hear analogue party)

The remaining analogue party in the call, can hear audio from the IP phone.

Looking in the active call help off the ip phone, this reports that no audio is being recieved by the ip phone from the analogue extension.

Looking at the SIP info off the SPA8000 I can see that no RTP packets are being sent from the SPA either, but this is receiving RTP from the IP Phone.

However if I put the caller on hold via hookflash on the analogue phone and then resume, 2 way audio is established.

All other transfer types work fine.

Does MOH work for calls put on hold via the spa8000 ? I get silence when doing so, and read that there are bugs in the latest firmware which I'm using 6.1.3 related to this. Can someone confirm on this? I've looked both here and on the cisco site, but can't find any info on this matter.

Appriciate your thoughts in advance.

David Harper · ‎07-21-2010

Hi Chaz,

Certainly this is not expected behaviour. Would it be possible for you to attach the UC500 and SPA configs, along with the output of 'debug ccsip message' covering the entire call setup, transfer, on hold, off hold process? If you are using CCA, then you can gather the SIP traces and UC500 config using the voice troubleshooting tools.

Cheers,

Dave.

mantis · ‎07-21-2010

Hi Dave,

I'll look at providing those logs, can you tell me how I'd attach the spa config? Is this involving saving html pages?

David Harper · ‎07-21-2010

Easiest way is to do a File > Save Page As... from your browser and save as a full web page. Make sure you are in Admin mode and have clicked the advanced link. The zip up all the files and attach it to the thread, or email it to me at dharper@cisco.com if there is any sensitive information in the config.

Cheers,

Dave.

antyeung · ‎07-27-2010

I was able to reproduce in the lab and I think I may have a solution for you.

When a phone on the SPA8000 does a transfer operation and completes the transfer, CME sends a reINVITE to the second analog phone with c=0.0.0.0 in the SDP attribute, which explains why there is one way audio b/c the SPA8000 is told to transmit RTP to 0.0.0.0.

005425: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:252@10.1.1.13:5160;ref=252 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.1:5060;branch=z9hG4bKEE0

Remote-Party-ID: <sip:251@10.1.1.1>;party=calling;screen=yes;privacy=off

From: <251>;tag=1E78AFC0-26F4

To: <252>;tag=5e2f3b8d44ad52a4i0

Date: Wed, 28 Jul 2010 03:24:53 GMT

Call-ID: 799DF90C-992E11DF-81A18FEC-835726@10.1.1.1

…

c=IN IP4 0.0.0.0

…

This seems to be a problem w/ CME but when I go back to the initial reINVITE that the SPA8000 sent to hold the call for the first phone I noticed that it included both c=0.0.0.0 along w/ the directional attribute a=sendonly to hold the call.

005410: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:

INVITE sip:252@10.1.1.1:5060 SIP/2.0

Via: SIP/2.0/UDP 10.1.1.13:5060;branch=z9hG4bK-5c88146c

From: <251>;tag=5c39e6c027d9eb8co0

To: <252>;tag=1E78AFD4-67C

Remote-Party-ID: <251>;screen=yes;party=calling

Call-ID: 1609ddd0-6aabdfbc@10.1.1.13

…

c=IN IP4 0.0.0.0

…

a=sendonly

I don’t believe this is per RFC which may be why CME would be sending 0.0.0.0 as the resume address.

What I did instead was under the SPA configuration utility > Voice > SIP, I changed the “RFC 2543 Call Hold” parameter from YES to NO and transfer worked in my lab setup.

Please give it a try and let me know if that work.

--

Anthony

mantis · ‎07-28-2010

This worked.

Good to know the exact cause and resolution.

Hopefully this will get added to be fixed in the next firmware release of this product.

Thanks

Chaz Cooper