Ringback, Ringback, Ringback where are you?

Ringback has been an issue that has surfaced quite a few times over the period I have worked with OCS R2 and nearly every time is surfaces it’s related to early media. It seems something relatively simple but it does seem hard to get right in the SIP world. I really want this post to be more of an analysis in nature rather than a he said she said type deal with RFC’s used to poke other vendors in the eye. In saying that I will take a look at what some of the claims being made by Cisco in their configuration documents and whether they can withstand the test of being compared to RFC information.

So what is ringback? According to RFC 3261:

"Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing)."

RFC 3261 does have some information about ringback and the way it is generated but doesn’t really go into the way it should be generated with the use of early media. RFC 3960 is the best resource on how things are supposed to function in a SIP world with early media and ringtone.

There is some interesting information in this RFC which depending on how a vendor implements it, could make a world of difference when doing interoperability. Let’s just say there are a lot of shoulds and coulds in this document that mean it is open for interpretation. It also calls out some complications for the methods of establishing early media for ringback in particular when signaling packets arrive at different times from media.

So I am not going to break down the RFC bit by bit but just call out a couple of interesting sections . The first one is:

“With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS ("Plain Old Telephone Service")-like SIP User Agent (UA) could implement the following local policy:

1. Unless a 180 (Ringing) response is received, never generate local ringing.

2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.

3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.

Note that a 180 (Ringing) response means that the callee is being alerted, and a UAS should send such a response if the callee is being alerted, regardless of the status of the early media session.”

This is a pretty interesting part because even though it begins with a SHOULD it pretty clearly defines how to implement early media and provide ringback. Keeping this in mind though it can provide some interesting issues which brings me to the next section:

“One important reason limiting the benefit of a potential early media indicator is the loose coupling between SIP signalling and the media path. SIP signalling traverses a different path than the media. The
media path is typically optimized to reduce the end-to-end delay (e.g., minimum number of intermediaries), while the SIP signalling path typically traverses a number of proxies providing different
services for the session. Hence, it is very likely that the media packets with early media reach the UAC before any SIP message that could contain an early media indicator.

Nevertheless, sometimes SIP responses arrive at the UAC before any media packet. There are situations in which the UAS intends to send early media but cannot do it straight away. For example, UAs using Interactive Connectivity Establishment (ICE) [6] may need to exchange several Simple Traversals of the UDP Protocol through NAT (STUN) messages before being able to exchange media. In this situation, an early media indicator would keep the UAC from generating a local ringing tone during this time. However, while the early media is not arriving at the UAC, the user would not be aware that the remote user is being alerted, even though a 180 (Ringing) had been received. Therefore, a better solution would be to apply a local ringing tone until the early media packets could be sent from the UAS to the UAC. This solution does not require any early media indicator.”

The passage above is kind of self-explanatory. If the media gets there in time all well and good. But if for some reason its delayed what should be done in the meantime. Guess what, play local ringback until it does. Sort of seems like a duh moment right there. This really lends itself to also the fact that just because its negotiated doesn’t mean that the UAS is going to send any media at all, so in that situation play local ringback.

This is pretty much follows how Office Communications Server implements early media to stop audio clipping during ICE negotiations. The Communications Server team talk about in their blog here.

Lets take a closer look how its done in OCS. Using a 183 session progress message with SDP the mediation server now waits for the PRACK response.:

Received:
SIP/2.0 183 Session Progress
FROM: "Norman, Christopher";tag=12495098-1453
TO: ;tag=7c679c5a62;epid=53CEB3AA6E
CSEQ: 101 INVITE
CALL-ID: 5399E937-489511DE-887FD928-A02D50B2@192.168.18.46
VIA: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK39F25
CONTACT:
CONTENT-LENGTH: 254
CONTENT-TYPE: application/sdp; charset=utf-8
ALLOW: UPDATE
REQUIRE: 100rel
SERVER: RTCC/3.5.0.0 MediationServer
Rseq: 1

v=0
o=- 46 1 IN IP4 130.42.18.28
s=session
c=IN IP4 130.42.18.28
b=CT:1000
t=0 0
m=audio 63940 RTP/AVP 0 101
c=IN IP4 130.42.18.28
a=rtcp:63941
a=label:Audio
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

The mediation server now waits for the PRACK response:

004386: May 25 19:01:45.793: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
PRACK sip:xch.contoso.com:5060;maddr=192.168.18.36;transport=Tcp SIP/2.0
Date: Mon, 25 May 2009 19:01:45 GMT
From: "Norman, Christopher" ;tag=12495098-1453
RAck: 1 101 INVITE
Allow-Events: telephone-event
Content-Length: 0
To: ;tag=7c679c5a62
Call-ID: 5399E937-489511DE-887FD928-A02D50B2@130.42.18.46
Via: SIP/2.0/TCP 192.168.18.46:5060;branch=z9hG4bK3A22AA
CSeq: 102 PRACK
Max-Forwards: 70

This establishes the media channel before the call has begun. This is pretty standard stuff. Early media can be negotiated with a 180 ringing message as well but in OCS’s case its use only the 183 w/SDP. In the case of OCS it does not send the ringback tone to the UAC. Therefor the local endpoint needs to have a policy as described in the RFC to overcome this and play ringback locally.

Here is where we run into some claims made by Cisco in their configuration documentation.

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf

"OCS 2007 R2 implementation of Early Media does not follow the standard implementation of the RFC used by the majority of PBX’s in the field. As a result Cisco UCM behavior might be different from what some early media test scenarios from the Microsoft test plan expect."

And:

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf

"Early-media negotiation may not be supported due to the new provisional response mechanism implemented on Microsoft OCS 2007 R2. Microsoft OCS 2007 R2 sends three provisional responses to a single INVITE (183 w/SDP, 180, 183) which causes incompatibility agaianst Cisco UBE which expects ringback media to flow from the Miscrosoft OCS due to the 183 with SDP response message (early media indication), but the Microsoft OCS does not send ringback media and the calling user never hears ringback. The workaround is to use the command “voice-class sip block 183 sdp present” and apply it to the appropriate dial-peer, not globally, in Cisco UBE to block all 183 messages from msft OCS toward
Cisco UCM allowing only 180 message to be sent to Cisco UCM and receiving local generated ringback on the calling side."

These are both interesting comments. First one makes the claim that Microsoft hasn’t followed a mysterious RFC which isn’t named that a majority of PBX’s in the field follow. Is this a very deceptive way of saying no one is following the RFC? I am not sure. Interesting that Cisco would call out an entire industry as not correctly following an RFC. The second is basically a fix because once a Cisco endpoint accepts the early media it no longer checks to see if there are any media packets to see whether it should still play a ringback local as the RFC suggests .Notice I use the word suggests. The RFC specifies should and not must for this functionality and only suggests a possible policy, so neither vendor is really in the wrong here. So do their claims stack up, well shaky at best I feel. Blaming Microsoft for broken functionality is really a stretch as I have proven in this case.

Below I have tried to gather a few things that may help with ringback issues with other vendors. I have outlined a few links and a possible fix where I can. Some of these are notes I have collected that I have not tested myself so as I said possible fixes.

Nortel

http://support.microsoft.com/kb/963126

Cisco

CUCM Direct SIP with OCS

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/861590.pdf

CUCM via CUBE to OCS

http://www.cisco.com/en/US/solutions/collateral/ns340/ns414/ns728/ns784/8464511.pdf

Technet discussion on Cisco ISR and ringback fix

http://social.microsoft.com/Forums/en-US/communicationsservertelephony/thread/b7f0c3d2-4e5b-4c92-aa7a-0b3541f758a9

Avaya

Ringback with OCS fixed CM 5.2.1 SP#2. If a call was made over a SIP trunk, the originator did not hear ringback if 183 Session Progress was received after 180 Ringing and the far end had already sent back SDP information either in 180 Ringing or 183 Session Progress.

If you have a ringback fix from another vendor let me know and I will post it up here.

Thanks to Dave and Aamer for providing me with ideas for this post.

Comments welcomed.

VoIPNorm