Dialogic Service Center

Service Contracts

Technical Helpweb

Downloads

Contact Support

Developer Forums

Training

Service Center Logon

Downloads

Product pages

Other downloads

Useful links

 

Technical Helpweb

Dialogic® Multimedia Platform for AdvancedTCA

Using SIPp for Call Generation

Background

As part of development and testing, it is often necessary to generate SIP calls into the 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. And finally, few SIP phones handle additional codecs such as AMR and EVRC used on the Multimedia Platform (MMP). How then, can SIP calls be done in this sort of environment?

The Wireshark PCAP files referred to in this article are available for download here. 

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. SIPp can be used for this. While 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 PCAP media stream also add 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.

SIPp:  http://sipp.sourceforge.net/


Technical Discussion

Building SIPp

Building SIPp is easy and well documented in the SIPp HTML documentation. One caution however - when 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 an XML file. So a combination of the two is needed to get the desired operation.

Two scenarios are supplied with this technote. The first is a multimedia client and 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 "videouac.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 "videouas.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 videouac.xml and videouas.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 Wireshark or tcpdump. This offers a great deal of 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 article. Starting both audio and video is done with the the following SIPp XML commands:

<exec play_pcap_audio="MMdemoMainmenuAMR.pcap"/>
<exec play_pcap_video="MMdemoMainmenuH263.pacp"/>

<pause milliseconds="26500"/>

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 - this case 26.5 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.

While 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 verifying both the SIP signaling and the resulting media streams. On the MMP, this should be 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 outbound 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 that the MMP application is listening on 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 up for audio, and 57344 and up for video. Each channel used increments the port number by 2.  SIPp port 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 here can also be very useful in working with 3G-324M calls that are available on the MMP. A full 3G mobile network connection will likely not be available. Even approriate 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.




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







Feedback

Please rate the usefulness of this page:  
0 - not useful at all
1 - potentially useful
2 - quite useful
3 - very useful
4 - exactly the information I needed     

Please enter a comment about this page: