De-facto standardization hurts 3G ring-back service

There are times when de-facto standards hinder the adoption and use of services. This is the case with 3G-324M and video ring-back servers.

What’s 3G-324M?

3G video telephony uses a protocol called 3G-324M. This protocol in turn, uses another protocol called H.245 for call control - with H.245, handsets signal what features and capabilities they have and negotiate the media channels that will be used in the call.

H.245 includes procedures and message that allow for the opening and closing of media channels. Every 3G video call starts with opening two channels: one audio channel and one video channel.

As with any other modern protocol, media is compressed using codecs. For 3G-324M, the audio codec is almost always AMR and the video codecs can be H.263 and MPEG4. More codecs will be added in the near future, but we’re not there yet.

It is important to note that 3G-324M is a point-to-point protocol. You have two participants in the call, with a dedicated “pipe” between them. No data is being signaled to other entities. These two participants are usually handsets, but sometimes - they can be servers. And this is where the problems begin.

Ring-back service

Video ring-back service is no different than the current audio ring-back service (this one is known in Israel as Fun-tone). With this service, the handset user can select a short clip (video clip in our case) that will be displayed to the caller when he dials and before he connects. It is such a successful service for audio devices, demand for video has grown substantially.

To implement this service in video, the call gets connected immediately when the caller dials out and a server on the network (the ring-back server) plays out the predefined video clip to the caller. In the meantime, the server dials out to the real destination and once that gets connected he continues to serve as a gateway between the two handsets (again due to limitations of the specification - its point-to-point…).

Ring-back server: basic call scenario

Messing it up…

What happens if the caller (the handset on the left) is capable of doing both MPEG4 and H.263 as its video codecs, but the callee (the handset on the right) is only capable of H.263?

As the ring-back server doesn’t know any of these two handsets or their capabilities in advance, it will try to serve as best as it can each handset. Going through the steps above:

1. Dial a call - The call will get connected. The Ring-back serer will notice that the handset can do MPEG4 and H.263. It might choose MPEG4 simply because it provides better video quality.
2. Send video clip - Now the server will send the predefined video clip in MPEG4 format.
3. Dial a call - The server dials out a call to the true destination.
4. Answer - The called person answers his phone and gets connected to the server with H.263.
5. Answer - Now the server needs to transcode MPEG4 and H.263.

Transcoding

Transcoding is usually a bad solution. The reason:

1. It takes up computing resources. Transcoding means the server must decode and encode everything it gets. This requires CPU-power, which means that a single ring-back server can only handle a limited amount of calls as it must save up resources for the duration of the call.
2. It adds latency. If everything you receive must be processed (decoded and then re-encoded) then you have to consider an additional delay. This delay/latency gets noticed and lowers the quality of experience for the end user.

Solutions?

There are two possible solutions:

1. Let the server “leave” the call somehow. Nice, but not that easy. There’s a feature called Session Reset in the H.324M standard, but it’s rather new and nobody uses it.
2. Renegotiate the channels. We can close the MPEG4 video channel and open an H.263 channel instead.

So where’s the catch?

Although H.245 and the 3G-324M standards allow you to close and reopen channels, nobody really implements it.

You have a large number of handsets on the market that simply drop calls if you close a channel in order to reopen it. It is a de-facto standard for 3G-324M handsets.

Server vendors, and to some extent operators, have been complaining about this for years now, but nobody listens. Handset vendors simply ignored this feature, and now, operators have a hard time deploying services.

It seems that some operators have had enough and are now looking for technical solutions for this issue. The 3G-324M Activity Group at the IMTC started thinking of solutions to this mess - I doubt if an easy and elegant solution will be found. More likely it will be a complex solution, with multiple options that will still include transcoding in some cases.