Dialogic Support Helpweb
Dialogic® Multimedia Platform for AdvancedTCA
How to use the SIPp utility as a convenient call source/sink when developing and testing Dialogic® Multimedia Platform applications
Summary
Using SIPp for Call Generation on Dialogic® Multimedia Platforms
Problem Description
AAn Advanced Telecommunications Architecture (ATCA) system is a major system in the world of personal computers. A developer or administrator will not tend to have an ATCA system running Dialogic's Multimedia Platform on his/her desktop for personal use. In addition, the ATCA system is designed to function in a Cental Office (CO) environment, and to be remotely accessed and controlled.
As part of development and testing, it is necessary to generate SIP calls into the ATCA system. This may not be possible from a remote location due to firewalls and other security restrictions. Most SIP soft phones are interactive and have GUIs that need to run under Windows® or X windows on Linux. Such a system may just not be available in a remote environment. Plus, few SIP phones handle additional codecs such as Adaptive MultiRate (AMR) codec and Enhanced Variable rate Codec (EVRC) used on the Multimedia Platform (MMP). How then, can SIP calls be made in this sort of environment?
Solution Summary
To get around these restrictions, a console-based, easily configurable SIP phone that can work with any type of audio or video media is needed. The SIPp utility can be used for this. Although it is generally used as a SIP load testing utility, it can be configured to interactively generate and accept single calls. Its call scenario flexibility and its ability to play any pre-recorded Packet Capture (PCAP) media stream also adds to its usefulness.
SIPp is an open source project, so it is freely available, and if necessary, it can be modified to suit any special requirements.
Technical Discussion
Building SIPp
Building SIPp is easy and well documented in the SIPp HTML documentation. One caution however - when Packet Capture (PCAP) files will be used to play media files as part of running the scenarios (see below) the following flag must be passed to "make" when building SIPp:
# make pcapplay
Using SIPp
There are two basic scenarios that are used to control the operation of a SIPp endpoint. It may either act as a client user agent (UAC) or as a server user agent.(UAS). A client generates a SIP call into a SIP target, while the server acts as a call sink from another SIP source. The operation of a SIPp endpoint is configured through both the startup options given it and via an XML file, so a combination of the two is needed to obtain the desired operation.
Two scenarios are supplied with this technote. The first is a multimedia client , the second a multimedia server. A shell script starts SIPp and the accompanying XML file describes the scenario.
Client Scenario
The files used are "runuac" and "uac.xml". A standard SIP protocol exchange is used to initiate and drop the call:
| SIPp Client | MMP Server | |
| INVITE | ----------------------------> | |
| ----------------------------> | Trying (OPT) | |
| ----------------------------> | Ringing(OPT) | |
| <---------------------------- | OK | |
| ACK | ----------------------------> | |
| Media | ----------------------------> | Media |
| Pause | ||
| BYE | ----------------------------> | |
| <---------------------------- | OK |
Server Scenario
The files used are "runuas" and "uas.xml". A similar SIP protocol exchange is used to receive, hold and respond to the dropped call:
| MMP Client | SIPp Server | |
| INVITE | ----------------------------> | |
| <---------------------------- | Trying (OPT) | |
| <---------------------------- | Ringing(OPT) | |
| <---------------------------- | OK | |
| ACK | ----------------------------> | |
| Media | <----------------------------> | Media |
| Hold Until Client Drops | ||
| BYE | ----------------------------> | |
| <---------------------------- | OK |
Media
Two types of media are offered in the SDP part of the SIP INVITE message. These are given in the uac.xml and uas.xml files:
m=audio [media_port] RTP/AVP 96 101
a=rtpmap:96 AMR/8000/1
a=fmtp:96 octet-align=1
a=rtpmap:101 telephone-event/8000
m=video [media_port+2] RTP/AVP 34
a=rtpmap:34 H263/9000
a=fmtp:34 CIF=1 QCIF=1 SQCIF=1
The audio portion uses Adaptive Multirate Codec (AMR), octet-aligned with RFC2833 DTMF. The video portion specifies H.263 for its codec. The variable [media_port] is set on the SIPp command line with the -mp option. The substitution is done when the XML script is run.
When the SIP call with the specified media is established, the client side, server side, or both, can start media streaming. The source of the media is a PCAP packet dump file, such as that collected by Ethereal or tcpdump. This offers flexibility in choosing codecs for use with SIPp. The SDP can be built and adjusted as needed, and any pcap recording of the protocol can be used to supply the packets.
An AMR audio recording (MMdemoMainmenuAMR.pcap) and an H.263 video file (MMdemoMainmenuH263.pacp) are included with this technote. Starting both audio and video, respectively, is done via the the following SIPp XML commands:
<exec play_pcap_audio="MMdemoMainmenuAMR.pcap"/>
<exec play_pcap_video="MMdemoMainmenuH263.pacp"/>
<pause milliseconds="8000"/>
The audio stream is played to the audio RTP port specified in the SDP INVITE/OK, and the video stream to the video port. The plays are done asynchronously in their own thread, so both are done simultaneously. For this reason, it is also necessary to pause XML script execution for the duration of the play - in this case 8 seconds.
Remember that a full duplex audio/video connection between a SIPp endpoint and HMP will consist of 4 streams:
SIPp Client -------- AMR ---------> HMP Server
SIPp Client <------- AMR ----------- HMP Server
SIPp Client -------- H.263 ---------> HMP Server
SIPp Client <------ H.263 ----------- HMP Server
Running the Scenarios
It may be helpful to test the two scenarios against one another before using them with an application on the MMP. The default startup scripts and their corresponding XML files will do this. Both are run on the same MMP.
Although SIPp allows its user to view a summary of the call as it is running, it is much more informative to record all of the details of a call. To do this, start up an ethernet monitoring utility such as Tethereal, or if working with an X windows desktop, Ethereal or Wireshark. This will allow for verifying both the SIP signaling and the resulting media streams. On the MMP, this is done by monitoring the "eth6" Ethernet interface.
Start the user agent server first with the "runuas" script, followed by the client script with "runuac". The scenarios will run their course. Stop the monitoring tool, and check the results. A full SIP call with 4 media streams (as shown above) should be seen.
The appropriate scenario can then be run against an MMP application. Choice of scenario depends on whether the MMP application generates an oubound call (use the SIPp server scenario) or expects an inbound call. (use the SIPp client scenario)
The SIP ports may need to be adjusted in the scenario startup scripts. Look for the following shell variables in the runuac script:
REMOTE_SIP_PORT=5060
LOCAL_SIP_PORT=5061
The remote port is the port on which the MMP application listens for incoming SIP messages. 5060 is the default. The local port (used by SIPp) can be any port that does not conflict with the MMP SIP port.
In the runuas script, only the local (SIPp) port needs to be set. It also must not conflict with MMP's SIP port.
Media ports will not likely need adjustment. The default RTP ports for an MMP application are 49152 and higher for audio, and 57344 and higher for video. Each channel that is used increments the port number by 2. SIPp ports are set to avoid conflict with the MMP port ranges. 50000/50002 are used as the starting ports for the UAC scenario for audio/video and 60000/60002 for the UAS scenario for audio video. Each new channel is also incremented by 2.
SIP and M3G
SIP and the SIPp scenarios described herein can also be useful in working with 3G-324M calls that are available on the MMP. A full 3G mobile network connection likely will not be available. Appropriate 3G test tools are expensive and sometimes difficult to use. A simple method of testing M3G calls may be done with the SIP to 3G gateway demo. Both scenarios would be used to run a loopback test of 3G. The call paths look like this:
| SIPp UAC | -------> | SIP-3G Gateway | -------> | 3G DTI loopback | -------> | SIP-3G Gateway | -------> | SIPp UAS | SIP | 3G-324M | 3G-324M | SIP |
Inbound and outbound calls using both protocols are generated using the UAC and UAS SIPp scenarios. For more details, see the documentation that accompanies the demo.
Product List
Dialogic® Multimedia Products
SIPp
Ethereal
Wireshark
Glossary of Acronyms / Terms
AMR = Adaptive MultiRate codec
ATCA = Advanced Telecommunications Architecture
DTMF = Dual Tone Mutliple Frequency touch tones
EVRC = Enhanced Varialbe rate Codec
M3G = 3rd Generation Media
MMP = Multimedia Platform
PCAP = Packet Capture
RTP = Real Time Protocol
SIP= Session Initiation Protocol
UAC = User Agent Client
UAS = User Agent Server
