I’m getting too old for this kind of thing! Give it a go at http://www.airkix.com/
By default, Genesys Stream Manager uses the URL specified in a SIP INVITE message to determine which announcement to play. The format of the URL is normally:
However, the “play” parameters can also be specified in the format “play=http://<xxx>;mode=stream” which enables stream mode for announcements obtained through a HTTP interface. The specified URL is assumed to correspond to a real-time media streaming device that provides an endless stream. Stream Manager does not cache the received data (except for what is necessary to provide jitter buffer). When a new request comes for the same URL, it will receive media stream when it connects to Stream Manager and not from the beginning of media file as in case of regular mode.
The play parameters can be specified in the “Text” field on the “PROMPT” tab of a play announcement block as shown in the test strategy below:
The Real Time Streaming Protocol (RTSP) is a network control protocol designed for use in entertainment and communications systems to control streaming media servers. The protocol is used to establish and control media sessions between end points.
The transmission of streaming data itself is not a task of the RTSP protocol. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery
The RTSP protocol has similarities to HTTP, but RTSP adds new requests. While HTTP is stateless, RTSP is a stateful protocol. A session identifier is used to keep track of sessions when needed; thus, no permanent TCP connection is required. RTSP messages are sent from client to server, although some exceptions exist where the server will send to the client.
Unfortunately, Stream Manager does not support RTSP at all. Rather, the Stream Manager HTTP interface works as follows:
- When the first SIP request comes for the particular HTTP source, Stream Manager tries to open TCP/IP connection to the specified host and port
- If the TCP/IP connection fails, Stream Manager responds with a 404 Not Found SIP message
- If the TCP/IP connection is successful Stream Manager sends the following HTTP request on the opened connection:
GET /xxxxxxx HTTP/1.1 \r\n
Host: xxxxxx \r\n
Accept: text/html, audio/x-wav \r\n
Connection: close \r\n
User-Agent: StreamManager/7.2.001.00 \r\n
- In response, Stream Manager expects the following HTTP message (on receiving response with code different from 200 OK, it will translate the error code into correspondent SIP response code sent to requester and close TCP/IP to the media gateway):
HTTP/1.1 200 OK \r\n
Content-Type: audio/x-wav \r\n
Raw audio stream or Audio in WAV format
- Any other HTTP header lines present in the response is printed into the Stream Manager log file, but otherwise ignored
- Stream Manager expects audio stream be either a header-less audio stream or a stream formed according to the WAV format standard, i.e. with standard WAV header, although Stream Manager ignores size fields of group header and data chunk in stream mode
- After getting the initial response, Stream Manger expects audio data coming at the appropriate rate (8000 bytes per second for G.711 codec). Alignment between audio frames and TCP/IP packet are not required, as Stream Manager uses internal jitter buffer between HTTP connection and RTP stream generator
The only known media server which works with the Genesys Stream Manager HTTP protocol is the Mayah Centauri product line (http://www.mayah.com/products/cent2-4000-overview.htm).
The challenge therefore is how to make Stream Manager work with other Media Servers such as Windows Media Services.
Windows Media Services
Windows Media Services (WMS) is a streaming media server from Microsoft that allows an administrator to generate streaming media (audio/video). Only Windows Media, JPEG, and MP3 formats are supported.
Windows Media Services 9 Series is available as an optional, installable component in the Standard, Enterprise, and Datacenter editions of Windows Server 2003.
Windows Media Services supports three out of the box streaming types:
- RTSP with TCP-based transport (RTSPT)
- RTSP with UDP-based transport (RTSPU)
- HTTP transport
The solution to this problem is some custom code which acts as a media stream proxy between Stream Manager instances and 3rd party media servers such as Windows Media Services which support the Real Time Streaming Protocol (RTSP).
The functionality of the media stream proxy is as follows:
- On startup ping each media server to check its availability
- Listen for HTTP requests from Stream Manager on a given port e.g. 9000
- When a HTTP request is received, parse the incoming URL for the name of a Windows Media Services broadcast point
- Connect to an available media server in priority order then send a “SETUP” request for the required broadcast point followed by a “PLAY” request
- If an error occurs send back a HTTP internal server error response