[cisco-voip] no Ringback on 7940-SCCP when calls are going over SIP

[Anthony Holloway]

There have been some good answers so far. I'd just like to offer the same
possible explanation, just worded slightly different.

SCCP phones which are SCCP version 19 and lower, do not support the getPort
message, and therefore cannot offer up a UDP port number to CUCM early
enough to allow CUCM to send Early Offer over a SIP trunk without the need
for an MTP.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/rel_notes/8_5_1/delta/delta.html#52746

Which phones and phone firmware combinations get you SCCP v20 support is a
bit unclear as seen below.

https://supportforums.cisco.com/discussion/11543476/sccp-phones-sccp-v20-support

Ringback tone is not generated locally, or cut through from the remote
side, until a progress message is receive by CUCM from the SIP trunk.  This
is typically a 180 or 183 response code.

There's really only two ways to go about ringback in this situation.

1.) If CUCM did in fact invoke an MTP to be able to send Early Offer, and
the SIP trunk responded with their Answer via a 1XX response code, and CUCM
sent a PRovisionalACKnowledgement which got ACKnowledge, and the far end
device was playing ringback (or some kind of audio), then the SCCP phone
should have heard ringback (or some kind of audio) from the far end device.

That's a big if, with lots of conditions.

2.) The other way, is to disable early media support on the SIP trunk all
together, so CUCM just instructs the phone to play ringback locally.  You
can do this as a test:  On your SIP Trunk's SIP Profile (make sure it's not
being shared with other devices as to not affect them), check the checkbox
for Disable Early Media on 180, save then reset your trunk.  Call will
drop.  I've seen CUCM gracefully tear down calls by sending out BYE's to
all active dialogs, and then drop the trunk.

Help on that setting says it all:

By default, Cisco Unified Communications Manager signals the calling phone
to play local ringback if SDP is not received in the 180 or 183 response.
If SDP is included in the 180 or 183 response, instead of playing ringback
locally, Cisco Unified Communications Manager connects media, and the
calling phone plays whatever the called device is sending (such as ringback
or busy signal). If you do not receive ringback, the device to which you
are connecting may be including SDP in the 180 response, but it is not
sending any media before the 200OK response. In this case, check this check
box to play local ringback on the calling phone and connect the media upon
receipt of the 200OK response

Note     Even though the phone that is receiving ringback is the calling
phone, you need the configuration on the called device profile because it
determines the behavior.

If that does end up fixing your issue, you just have to decide if early
media on that trunk is a requirement or not.  If so, either replace your
phones with newer phones (SCCP v20+) or as the far end if you can create a
separate trunk to them, specifically for this work around, and then via
CSS/PT you steer these legacy phones over the work around trunk, while
everyone else uses the existing trunk.

As for why it only start when you moved to CUCM 10x....I'm not certain.
 During an upgrade, settings usually just carry over.  And Cisco is not in
the habit of turning on new features or nerd knobs which would contradict
early default behavior (I.e., If early offer was off by default in 8.5, it
would not be on by default in 10.5).

On Wednesday, September 17, 2014, Nathan Reeves <nathan.a.reeves at gmail.com>
wrote:

> Anyone come across anything like 7940's not playing Ringback to the user
> when an external call is made out externally over a SIP trunk.
>
> CUCM is V10.  Firmware on the 7940's is as up to date as possible.  Calls
> proceeded normally on CUCM 8.5 normally.  Only noticed this on the move to
> V10.
>
> Thanks
>
> Nathan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140917/61bbe19d/attachment.html>