Jump to content

Captivate Global

  • Posts

  • Joined

  • Last visited

Captivate Global's Achievements


Newbie (1/14)



  1. 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?
  2. When I attempted to set this up using a similar playback method (vlc transcoding into ulaw and streaming to the entered port) I ran into a major issue. The issue is that every second phone call placed on hold plays a single audio packet over and over. Taking the call off hold and placing it back on hold results in a smooth stream where each audio packet is played in the correct order. (let's call it "first and second slot" on hold - the first slot works, the second just loops the last packet over and over) However, cycling hold again will repeat the last audio packet over and over and over. Cycling again results in a smooth stream. Stopping the player results in all on-hold activities looping the last packet. Placing a call on hold in 'First Slot' while the player is stopped, then starting the player, will restore the audio stream when the player is rebooted. Placing a call on hold in the 'Second Slot' while the player is stopped, then starting the player, continues to loop the last audio packet over and over. I read that the RTP stream used to be an internal thing in the CS410 where a player streamed to an RTP port on it's local interface. Perhaps the PBX is still looking for this source on every second try?
  3. Hi were you able to get resolution? on this forum post?


    also how can we reproduce this? are you using VLC if so what is the syntax you are using? so we can start testing this here.

  4. 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?
  5. 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.
  • Create New...