Jump to content
Vodia PBX forum
Captivate Global

RTP Stream Input / Multiple Live MoH

Recommended Posts

We are a music on hold provider and we are currently attempting to integrate our solution for a hosted snomONE system here in Australia.

 

Our solution is capable of delivering content for music on hold in a number of live and non-live ways, coming down to three main sections - streaming, file-based, or analogue audio jack. All of our solutions deliver or attempt to deliver a 'live stream' sounding experience for a number of sections of each business.

 

We are trying to implement a number of different clients' live streams on the same machine - there are several businesses which all have their own promotional on-hold material whom all use the same hosted system. Given this, we have two options: deliver files, or deliver stream. File delivery often poses security questions as providers rarely will let you upload files directly to their hosted systems. In this circumstance, considering we need to deliver multiple on-hold sources to the same machine, we need to use the RTP stream method.

 

For example, one of our clients (non-SNOM) uses a total of three on-hold 'playlists' which are played back depending on which queue the caller dials into - the sales queue promotes product, the support queue answers FAQs and the general on-hold promotes the business itself. Their system supports this by the use of multiple RTP streams, it is not capable of three audio inputs and the MoH system must be restarted to change source files.

 

That being said, we are experienced in delivering RTP streams to be used for content within a SIP session. We are also capable of delivering audio via a SIP session itself - our device registers as an extension and answers any phone calls with the MoH content requested via URI. We have attempted to setup our solution delivering to the snomONE system as detailed above but have run into some issues.

 

There are a few, but the main issue is that for every second person whom is placed on hold, the music on hold does not work correctly - a horrible loud looping static-y noise is played instead.

 

The steps we have taken to produce this issue is:

 

• Create a MoH Source of type RTP Stream – any port (we chose 5005)

• Set a queue to use this source as a ringback or extension to use for hold music

• Send an RTP audio stream in ulaw to the listening port with 20ms packet timing

• Have one caller placed on hold or in the ringback queue – this should work successfully

• Keep the first caller on hold as a ‘test’ – put another extension on hold.

• Both callers will receive the horrible static noise (first callers MoH will stop and be replaced by this)

• Keeping both calls on hold, place ANOTHER call on hold.

• All three calls resume normal MoH activity

 

It seems as if the PBX is swapping between one source and another. Packet capturing on the PBX reveals that the audio content switches between what is being received on the RTP port, and '7f7f7f7f7f7f7f7f7f7f7f' - capturing the payload of the stream and saving it to a wave file, you can hear it switching between each stream.

 

Additionally, if you create a MoH source of the type 'RTP Stream' and set nothing up to send to it, place someone on hold, you receive this noise (7f7f7f7f7f7f7f). I would expect if nothing is being received on the RTP port then this stream would have silence - instead it's got this odd content being generated - where from? Upon receiving something to the port, it starts to send this information instead.

 

We have logged a ticket with snom via the provider we are integrating with, however I thought I would post on the forums to see if anyone has had any experience with delivering RTP streams to SNOM.

Share this post


Link to post
Share on other sites

The design for the RTP MoH originally comes from the CS410, where another subsystem provides the RTP stream in G.711 format. In that environment, it seems to be working reasonably okay.

 

The RTP MoH uses a small internal buffer with a read and a write pointer. The speed of the read pointer is determined by the internal 8 kHz sampling frequency clock for the media playout. The write pointer speed is determined by the RTP input. If the read and the write speed differ too much, then you will have the effect of wrap-around. Usually the problem is not the overall speed difference, the problem are jitter on the RTP side. Maybe this is the problem here. A simple wireshark trace would show this.

 

We could dramatically increase the buffer to reduce the problem. However before we do that we should unstand what exactly the problem is. Otherwise we just make the problem less obvious, but still there.

Share this post


Link to post
Share on other sites

The RTP MoH uses a small internal buffer with a read and a write pointer. The speed of the read pointer is determined by the internal 8 kHz sampling frequency clock for the media playout. The write pointer speed is determined by the RTP input. If the read and the write speed differ too much, then you will have the effect of wrap-around. Usually the problem is not the overall speed difference, the problem are jitter on the RTP side. Maybe this is the problem here. A simple wireshark trace would show this.

 

We could dramatically increase the buffer to reduce the problem. However before we do that we should unstand what exactly the problem is. Otherwise we just make the problem less obvious, but still there.

 

I'm not sure that's the issue, though. Wireshark traces show acceptable jitter (mean 0.10ms max 0.20ms). Using Wireshark to dump the payload of an RTP stream will result in an audio file that works perfectly. As mentioned, if you place one person on hold and then use a second extension to place another call on hold, both calls will get the repeating audio. The next time you place someone on hold, all calls will return to normal.

 

Each time you place a person on hold, the source for EVERY call changes. This has resulted in a perfectly formatted audio file coming out of the RTP stream, but with looping audio in the places where the issue has occured. The looping audio lasts for a few seconds before I had placed another extension on hold and the hold music went back to normal.

 

If you go on hold with an RTP source that's never had traffic sent to it, you receive a grinding electronic noise - however, if that port has received packets in the past, it will loop those audio packets instead. It's almost like the internal buffer is having issues moving it's pointer for every second hold operation that is performed.

 

I find it hard to point to any issue with the source stream, as I have mentioned the same solution is in use to deliver MoH for a number of other platforms across differing quality links; we have rarely had any issue with jitter or latency, and I don't believe that there is any issue with the source itself in this circumstance - as it looks and sends audio like any RTP device does.

 

I think that somewhere in the code, it is possible that the RTP MoH is still looking for this 'internal feed' that you have mentioned. It is certainly strange behaviour, as the playback works perfectly otherwise. I have read some other posts on RTP MoH and it seems most are using a virtual loopback with an on-system player. One post mentions he has made VLC send audio directly to the RTP port which was working as intended - but does not mention this issue.

 

It may be worth noting that we also use VLC to deliver RTP streams, however it has been modified to send 20ms packets instead of the default behaviour in which it will send 16.666ms packets. We attempted using stock VLC to deliver the audio, however it did not work at all in any configuration with any type of source file - much the same as other platforms, it just makes a horrible noise as the packet times are outside what is expected by most IP platforms.

 

Has anyone else successfully implemented an RTP source and used it without this behaviour?

Share this post


Link to post
Share on other sites

Hi there,

 

Just stopped past to read some new posts and noted that there hasn't been any replies to this thread.

 

This is a pretty major bug which means the snomONE system is completely unable to use an external music on hold source. We know that several clients of our integrator have moved to other systems as a result of not being able to use live MoH services. When your phone provider says to you 'We logged the bug with the vendor last year, we'll get back to you when they get back to us' then it does not fill you with confidence.

 

Why is there not more attention paid to this?

Share this post


Link to post
Share on other sites

As posted in another thread, we did spnd some time on it and there is a problem when the packet length is not 10, 20, 30, 40 (multiple of 10) ms. This is typical in the telecom world... If the packet length is not multiple of 10 ms, the PBX seems to have problems with the internal wrap-around (leaving a noise carpet at the end of the buffer). We made a code change that should make it possible to send any length for MoH, we are investigating it. If you would like to check as well, send a PM and we'll send you a link to a build for verification.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...