Testing SIP with SIPP

Want to test your Asterisk PBX system if it can sustain load and large traffic? Then you can use this tool.
Sipp is a performance testing tool for the SIP protocol. Its main features are basic SIPStone scenarios, TCP/UDP transport, customizable (xml based) scenarios, dynamic adjustement of call-rate and a comprehensive set of real-time statistics.
Sipp can be used to test real SIP equipments and very useful to emulate thousands of user agents calling your SIP system.

Installation:

1.    Download the stable version of Sipp ( sipp-xxx.tar.gz)
2.    Uncompress the tarball file
#tar zxvf sipp-xxx.tar.gz
#cd sipp
#make

Using Sipp:

SIPp allows to generate one or many SIP calls to one remote system
Syntax: ./sipp -sn uac ip
#./sipp –sn uac 127.0.0.1
#./sipp -sn uac 192.168.17.10

Traffic Control:

SIPp generates SIP traffic according to the scenario specified. You can control the number of calls (scenario) that are started per second. This can be done either:
•    Interactively, by pressing keys on the keyboard
o    ‘+’ key to increase call rate by 1
o    ‘-‘ key to decrease call rate by 1
o    ‘*’ key to increase call rate by 10
o    ‘/’ key to increase call rate by 10
•    At starting time, by specifying parameters on the command line:
o    “-r” to specify the call rate in number of calls per seconds
o    “-rp” to specify the “rate period” in milliseconds for the call rate (default is 1000ms/1sec). This allows you to have n calls every m milliseconds (by using -r n -rp m).
Note
Example: run SIPp at 7 calls every 2 seconds (3.5 calls per second)
./sipp -sn uac -r 7 -rp 2000 127.0.0.1
You can also pause the traffic by pressing the ‘p’ key. SIPp will stop placing new calls and wait until all current calls go to their end. You can resume the traffic by pressing ‘p’ again.
To quit SIPp, press the ‘q’ key. SIPp will stop placing new calls and wait until all current calls go to their end. SIPp will then exit.

Changing Screens:

Several screens are available to monitor SIP traffic. You can change of screen by pressing 1, 2, 3 or 4 keys on the keyboard.

Key ‘1’: Scenario screen. It displays a call flow of the scenario as well as some important informations.
Key ‘2’: Statistics screen. It displays the main statistics counters. The “Cumulative” column gather all statistics, since SIPp has been launched. The “Periodic” column gives the statistic value for the period considered (specified by -f frequency command line parameter).
Key ‘3’: Repartition screen. It displays the distribution of response time and call length, as specified in the scenario.
Key ‘4’: Variables screen. It displays informations on actions in scenario as well as scenario variable informations.

Some SIP stuff

1. How c-seq count is used by UAS to determine out of sequence request

 

# CSeq numbering is independent for requests originated by each end. Note that while the UAC is expected to use consecutive values, the UAS is expected to allow gaps in the numbering. This is needed in case messages get lost along the way.

2. How registration can be removed with a Retry-After header .

 

# This question is not clear to, however if you are asking in the terms of SIP Proxy here you go.

 

An SIP Proxy Server which is overloaded or administratively disabled MAY generate a 503 Service Unavailable response to a REGISTER request, and SHOULD include a Retry-After header value indicating how long before the SIP-PBX SHOULD re-attempt the request to the same SIP Proxy Server.  An SIP-PBX receiving such a response MUST support the Retry-After header, and MUST honor the value as follows: if the value is 32 seconds or less, it MUST wait the requested time and retry the request to the same SIP Proxy Server; if the value is larger, it MUST remember the value for that SIP Proxy Server address instance, and try any alternate SIP Proxy Server addresses it can.  If an alternate SIP Proxy Server can be successfully reached and Registration succeeds through the alternate, the SIP-PBX MAY discard the Retry-After value of the original.  Otherwise, it MUST wait to reattempt Registration to the original SIP Proxy Server for the Retry-After value in seconds. 

 

3. Use of rport and received parameter used in the via header field

 

# When a server attempts to send a response, it examines the topmost Via header field value of that response. If the "sent-protocol" component indicates an unreliable unicast transport protocol, such as UDP, and there is no "maddr" parameter, but there is both a "received" parameter and an "rport" parameter, the response MUST be sent to the IP address listed in the "received" parameter, and the port in the "rport" parameter. The response MUST be sent from the
same address and port that the corresponding request was received on. 

 

4. Difference between loose routing and strict routing

 

# Strict Routing rewrote the Request-URIii. That means the Request-URI always contained URI of the next hop (which can be either next proxy server which inserted Record-Route header field or destination user agent). Because of that it was necessary to save the original Request-URI as the last Route header field.

 

# Loose routing,  works in a little bit different way. The Request-URI is no more overwritten, it always contains URI of the destination user agent. If there are any Route header field in a message, than the message is sent to the URI from the topmost Route header field. This is significant change--Request-URI doesn't necessarily contain URI to which the request will be sent. In fact, loose routing is very similar to IP source routing.

5. Use of q parameter in the contact header field

 

# "q"  & "expire" parameters are only used when the Contact is present in a  REGISTER request or response, or in a 3xx response.  Additional
  parameters may be defined in other specifications. 

 

The "q" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record.

How Mediaproxy works ?? how opensips and mediaproxy works together to solve NAT problems

This NAT traversal solution operates by placing a media relay in the middle between 2 SIP user-agents. It mangles the SDP messages for both of them in a way that will make the parties talk with the relay while they think they talk directly with each other.

Mediaproxy consists of 2 components:

• The OpenSIPS mediaproxy module
• An external application called MediaProxy which employs a dispatcher and multiple distributed media relays. This is available from http://ag-projects.com/MediaProxy.html (version 2.0.0 or newer is required by this module).

The mediaproxy dispatcher runs on the same machine as OpenSIPS and its purpose is to select a media relay for a call. The media relay may run on the same machine as the dispatcher or on multiple remote hosts and its purpose is to forward the streams between the calling parties. To find out more about the architecture of MediaProxy please read the documentation that comes with it.

To be able to act as a relay between the 2 user agents, the machine(s) running the module/proxy server must have a public IP address.

OpenSIPS will ask the media relay to allocate as many ports as there are media streams in the SDP offer and answer. The media relay will send back to OpenSIPS the IP address and port(s) for them. Then OpenSIPS will replace the original contact IP and RTP ports from the SDP messages with the ones provided by the media relay. By doing this, both user agents will try to contact the media relay instead of communicating directly with each other. Once the user agents contact the media relay, it will record the addresses they came from and will know where to forward packets received from the other endpoint. This is needed because the address/port the NAT box will allocate for the media streams is not known before they actually leave the NAT box. However the address of the media relay is always known (being a public IP) so the 2 endpoints know where to connect. After they do so, the relay learns their addresses and can forward packets between them.

The SIP clients that will work transparently behind NAT when using mediaproxy, are the so-called symmetric clients. The symmetric clients have the particularity that use the same port to send and receive data. This must be true for both signaling and media for a client to work transparently with mediaproxy without any configuration on the NAT box.

engage_media_proxy()

Trigger the use of MediaProxy for all the dialog requests and replies that have an SDP body. This needs to be called only once for the first INVITE in a dialog. After that it will use the dialog module to trace the dialog and automatically call use_media_proxy() on every request and reply that belongs to the dialog and has an SDP body. When the dialog ends it will also call automatically end_media_session(). All of these are called internally on dialog callbacks, so for this function to work, the dialog module must be loaded and configured.

This function is an advanced mechanism to use a media relay without having to manually call a function on each message that belongs to the dialog. However this method is less flexible, because once things were set in motion by calling this function on the first INVITE, it cannot be stopped, not even by calling end_media_session(). It will only stop when the dialog ends. Until then it will modify the SDP content of every in-dialog message to make it use a media relay. If one needs more control over the process, like starting to use mediaproxy only later in the failure route, or stopping to use mediaproxy in the failure route, then the use_media_proxy and end_media_session functions should be used, and manually called as appropriate. Using this function should NOT be mixed with either of use_media_proxy() or end_media_session().

This function can be used from REQUEST_ROUTE.

Example 1.8. Using the engage_media_proxy function

...
if (method==INVITE && !has_totag()) {
    # We can also use a specific media relay if we need to
    #$avp(media_relay) = "1.2.3.4";
    engage_media_proxy();
}
...
        

911 with sip | 911 Handling in VOIP by Andrewjprokop

Have you ever had the need to dial 9-1-1? Unfortunately, I have. It was just one time, but one time is enough for me. I won’t bother you with the details, but minutes after the call was answered, a swarm of paramedics had converged on my house and although the emergency was resolved seconds prior to their arrival, I am grateful that the right people could be summoned so quickly.

According to that National Emergency Number Association (NENA), 240 million 9-1-1 calls are made each year. The FCC adds that one third of those calls are from wireless telephones. In some communities, nearly one half of the 9-1-1 calls are made from cell phones. Clearly, the need for this single number to call for help is extremely valuable.

9-1-1 has been around since 1968, but I highly doubt that most of those 240 million people knew what was happening when they made their calls.

How do the calls end up at the right place? How do the emergency response agents know where the calls are coming from?

Before I delve into explanations, allow me to define a few terms.

NENA. The National Emergency Number Association (NENA) is the organization responsible for fostering the technological advancement, availability, and implementation of an emergency telephone number system in the United States.

PSAP. A Public Safety Answering Point (PSAP) is a call center responsible for answering 9-1-1 calls. As of April 2014, the United States has 5,976 primary and secondary PSAPs in 3,135 counties, parishes, independent cities, boroughs and Census areas.

ELIN. An Emergency Location Identification Number (ELIN) is a North American dialing plan number used to represent one or more telephone extensions off a PBX. The telephones that use the same ELIN should be physically located near one another. ELINs can be used when it is not necessary to identify the exact location of every telephone in a business.

ANI. Automatic Number Identification (ANI) is a ten-digit number sent from a telephone on the public network. Like an ELIN, it identifies the caller.  However, ANI is generally assigned to a more precise location.

ERL. An Emergency Response Location is typically used by a PBX to define telephone locations. A company may have many ERLs, but fewer than the number of employees or DID numbers.  An ERL might be the company address along with information about a location within that address (e.g. southwest corner of the second floor). Several ELINS may be assigned to a single ERL.

Selective Router. Also referred to as a Tandem Router, a Selective Router uses an ANI/ELIN to find the correct PSAP for an emergency call.

MSAG. The Master Street Address Guide database maintains the ELIN to PSAP mapping and is used by the Selective Router.

PS-ALI. The Private Switch Automatic Location Identifier database is used by the PSAP to map ANI/ELINs to caller information. This provides the emergency response agent with the ALI for the caller.

ALI. Automatic Location Identification (ALI) provides the PSAP agent with location information about the 9-1-1 call.  ALI consists of the following:

• Phone number
• Location, 20 characters
• Customer name
• Street directional
• Street name
• Community and state

Whew! Does that sound a little overwhelming? Actually, once you understand the basic call flow, it’s not that bad. To assist you in understanding how it all comes together, let’s take a look at a very simple example.

1. Someone makes a 9-1-1 call. The caller is identified by his or her ANI or ELIN. ANI if the call is from a telephone on the public network. ELIN if the call is from a private network such as a PBX. Remember, ERLs are used to map locations within a business to  ELINs.
2. The Telephone Company/Selective Router uses the ANI/ELIN to search the MSAG to determine which PSAP should handle the call.  The call is then sent to that PSAP.
3. When the call arrives at the PSAP, the ANI/ELIN is passed to the PS-ALI database to determine the correct ALI for this call.
4. The call is routed to an agent along with the retrieved ALI.
5. If necessary, emergency response providers are dispatched to the location described within the ALI.

9-1-1 from a cell phone is a little more complicated, but by using cell tower triangulation, the caller’s location can also be determined.

That’s not so bad, is it? As long as the call is made to the appropriate place and the ANI/ELIN matches an entry in the PS-ALI database, the emergency will be efficiently handled.

* Image from Wikipedia.

However, what if the call isn’t sent to the appropriate place or the ALI cannot be determined from the ANI/ELIN? These are the issues that arise from IP telephony.

In the TDM world, telephones are pretty static. You plug your phone into a jack that is directly connected to wire that terminates on a port off your PBX. This makes it pretty easy to match caller to location.

Additionally, the telephones and PBX are in the same location and the PBX has TDM trunks to the local telephone company. So, if a user off a PBX in Bloomington, Minnesota makes a 9-1-1 call, the chances are extremely high that it will be answered at a nearby PSAP.

IP Telephony Brings Issues

SIP phones aren’t physically tied to a PBX. This is especially true with a SIP client on a mobile device. With SIP, I can make calls regardless of where I am. However, it won’t do me any good if I have an emergency in Illinois and the 9-1-1 call is answered by someone in Minnesota. Clearly, something needs to be done to connect callers with the correct emergency responders.

Ignoring the case of mobile or remote SIP for a moment, this is where the ERL can be used. ERLs can be associated with ports on LAN switches. An ERL for one group of ports might map to one set of ELINs and the ERL for another group of ports might map to a different set of ELINs. ELINs from the first group could equate to floor 1, Pillar 6 at a company’s address and ELINs from the second group could equate to Floor 2, Pillar 3 at that same address.

ERLs can also be associated with wireless adapters for in-building mobility.

I should point out that there are a variety of companies (911 ETC, Conveyant, RedSky, 911 Enable, Amcom, etc.) that offer products that work with your PBX to assist in mapping IP telephones to ERLs.

ERLs and ELIN mapping doesn’t solve everything, though. You need to make sure that the ELIN is sent to the correct place in order for the Selective Router to find the appropriate PSAP. This requires 9-1-1 calls to be sent out on the right trunks.

9-1-1 routing isn’t overly complicated when trunks coexist with the users they serve. This means trunks exist at both the main site and any gateways off the PBX. Route tables are configured to send 9-1-1 calls out the appropriate local trunk no matter where the telephone is receiving its call control processing (main or gateway).

It becomes complicated for branch offices when a company eliminates trunks from their remote gateways and centralizes all calls on SIP trunks. In this case, there is no connection between a remote location and its PSAP.

Thankfully, there are companies that offer cloud based solutions to map remote IP users to the correct PSAP. Three that come to mind are RedSky, 9-1-1 Enable, and 911 ETC. All allow you to send 9-1-1 calls directly to their clouds. Their clouds will then route 9-1-1 calls to the appropriate places. For example, you might consolidate all your trunks in Chicago and have a “trunkless” gateway in Minneapolis. If a Minneapolis user makes a 9-1-1 call it will be sent out a SIP trunk in Chicago to a cloud service which will then send the call back to Minneapolis and the correct PSAP.

Mobile Users

Unfortunately, there is still a hole when it comes to mobile SIP clients. I could be wrong, but I don’t know of any solution that allows you to place a 9-1-1 call from a SIP client on an iPhone or Android connected to a 3G or 4G network. In this case, the call must either be disallowed by the client software or the soft-phone must place the call on the cellular connection.

At some point, I would love to see SIP messages imbed location information such as GPS coordinates and have that used to route calls, but I know of nothing on the horizon that allows for that.

Wrapping Things Up

I didn’t expect this article to be this long, but once I got going it was hard to know when to stop. Hopefully you’ve learned something over these past three or four pages and are now prepared to dig into 9-1-1 even deeper than I’ve taken you. If you are going to implement 9-1-1 on your PBX, I would highly recommend that you take the extra steps to become even more knowledgeable. You don’t want to mess around when it comes to life or death situations.

Originally Shared on SIP Adventures by Andrew prokop

What is Min-SE Header in SIP Message

When a UAC sends an INVITE, it includes a Supported header field with the option tag 'timer', indicating support for this extension. This request passes through proxies, any one of which may have an interest in establishing a session timer. Each proxy can insert a Session-Expires header field and a Min-SE header field into the request (if none is already there) or alter the value of existing Session-Expires and Min-SE header fields.

If the Session-Expires interval is too low for a proxy (lower than the value of Min-SE that the proxy would wish to assert), the proxy rejects the request with a 422 response. That response contains a Min-SE header field identifying the minimum session interval it is willing to support. The UAC will try again, this time including the Min-SE header field in the request. The header field contains the largest Min-SE header field it observed in all 422 responses previously received. This way, the minimum timer meets the constraints of all proxies along the path.

After several INVITE/422 iterations, the request eventually arrives at the UAS. The UAS can adjust the value of the session interval as if it were a proxy; when done, it places the final session interval into the Session-Expires header field in a 2xx response. The Session-Expires header field also contains a 'refresher' parameter, which indicates who is doing the refreshing -- the UA that is currently the UAC, or the UA that is currently the UAS. As the 2xx response travels back through the proxy chain, each proxy can observe the final session interval but can't change it.   

From the Session-Expires header field in the response, both UAs know that a session timer is active, when it will expire, and who is refreshing. At some point before the expiration, the currently active refresher generates a session refresh request, which is a re-INVITE or UPDATE request. If the refresher never gets a response to that session refresh request, it sends a BYE to terminate the session. Similarly, if the other side never gets the session refresh request before the session expires, it sends a BYE.   

The refresh requests sent once the session is established are processed identically to the initial requests, as described above. This means that a successful session refresh request will extend the session, as desired.

=======================================================================

In Simple Words :

Min-se is the minimum value of timer , when UAS / UAC needs a session refresher.

For ex:

Let's UAS has configured Min-Se as 200 sec. UAC sends an INVITE with session-expire with Value less than 200 sec (ex 100 sec).

Then UAS sends 422 interval too small with Min-se value 200.

So that UAC will aware of the minimum session refreshment required for UAS.

It needs because UAS should not overload with lots of session refreshment ( Re-INVITES and UPDATES) for a single dialog.

You can increase the min-se value with both party agreement.

Presence server implementation | SIP Notify, publish and subscribe messages by andrew jprokop

 (Source : http://andrewjprokop.wordpress.com/ )

Are you familiar with busy lamps on telephones? For many years, they were the only way you could “see” the telephone status of a coworker.

For example, let’s say that Andrew is the administrative assistant to Debbie and as part of his job, Andrew needs to know when Debbie is on and off the phone. For that to happen, a busy lamp is configured on Andrew’s telephone. Now, when Debbie is on the phone, the busy lamp on Andrew’s telephone lights up. When Debbie is off the phone, the lamp goes dark.

Pretty simple, isn’t it?

However, despite the fact that Andrew knows when Debbie is on her desk phone, does he know when she is on her cell phone? He doesn’t. The busy lamp only informs Andrew of Debbie’s desk phone activity. It has no idea about Debbie’s other devices.

Does it tell Andrew the nature of Debbie’s call? Can he distinguish an important call from something that can be interrupted? Nope.

Also, what does the lamp being unlit say? Well, it tells Andrew that Debbie is off the phone. Does it tell him that Debbie is in the office? No. Does it tell him that Debbie is in the office, but busy working on huge proposal and doesn’t want to be disturbed? Again, no. It’s just a light that’s either on or off.

Clearly, a busy lamp is fairly limited in its usability in today’s hyper-connected world and something more informative is required.

Enter presence. Presence conveys on-the-phone and off-the-phone information like a busy lamp, but that’s just the beginning. Presence can also tell you that the user is out of the office, hasn’t touched his or her PC in so many minutes, doesn’t want to be disturbed, is in a meeting, is on a conference call, has left for lunch, is sick and working from home, etc.

In other words, presence is a busy lamp on steroids.

Presence and SIP

Full disclosure, SIP is not the most common way to implement presence. That distinction goes to XMPP. However, SIP is gaining fast on XMPP and more and more applications are replacing XMPP with SIP. Case in point, Google Hangouts has recently announced that it will soon be using SIP for presence and Instant Message.

For a deeper dive into XMPP vs. SIP, please refer to my article Some Pontification on XMPP and SIMPLE.

Before I go too much further, allow me to define a few of the terms used in presence.

Watcher. A watcher is a SIP entity interested in the presence status of another SIP entity. A watcher sends a SIP SUBSCRIBE message to express its desire to receive presence information.

Presentity. A presentity is the entity being watched. It sends a SIP PUBLISH message when its status changes.

Presence Server. A presence server acts as a broker between the watcher and the presentity. The presence server receives SUBSCRIBE messages from watchers and PUBLISH messages from presentities.   Upon receipt of a PUBLISH, the presence server will send SIP NOTIFY messages to all subscribed watchers.

Expressed in a simple picture, we have this:

The next thing we need is a way to convey presence information from the presentity to the watcher. Although this could be accomplished in a number of different ways, most SIP applications have standardized on XML. Specifically, the PUBLISH message from the presentity and the NOTIFY message to the watcher will contain something referred to as Presence Information Data Format (PIDF).   PIDF will be represented in XML and labeled PIDF+XML within the NOTIFY and PUBLISH messages.

Over the years, I have seen the PIDF variants extended PIDF, xpidf+xml, and rich PIDF, rpidf+xml. These variants provide additional information about the presentity’s state.

As an example, here is a PUBLISH message that might be sent from a presentity when it goes on-line.

PUBLISH sip:Andrew@example.com SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

To: <sip: Andrew@example.com>

From: <sip: Andrew@example.com>;tag=1234wxyz

Call-ID: 81818181@pua.example.com

CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: 241

<?xml version=”1.0″ encoding=”UTF-8″?>

<presence xmlns=”urn:ietf:params:xml:ns:pidf”

entity=”pres: Andrew@example.com”>

<tuple id=”efeef223″>

<status>

<basic>open</basic>

</status>

<timestamp>2014-05-01T17:00:19Z</timestamp>

</tuple>

</presence>

Rather than trying to explain the PUBLISH message and PIDF+xml in great detail, allow me to point out a few of the most important aspects.

• The To and From headers are the same and always refer to the presentity. In this case, Andrew is advertising his presence status update.
• Content-Type is set to application/pidf+xml. This defines the format of the message body.
• The Event is presence.
• The status element contains the presence state. In this case, “open” maps to on-line. A status of “closed” would indicate off-line. A status of “inuse” would indicate on-line and busy.
• The presentity is Andrew. You will see that in the PUBLISH message and the XML message body.

On-line and off-line are certainly important to know, but the goal of presence is not to simply mimic a busy lamp. That’s where additional XML elements come into play.

For instance, an activities element further defines status.  A status of “inuse” and an activities of “on-the-phone” indicates that the user is active on a telephone call.

A note element might tell the watcher that the presentity is in a meeting until 1:00.

There is even a mood element that conveys information such as afraid, amazed, and disgusted.

It’s also possible to pass location information in a presence update. Knowing that someone is available at work on Monday or available at home on the weekend might elicit different behavior on the part of those who wish to contact the presentity.

There are endless possibilities of how presence might be refined.

Finally, presence can be aggregated. This allows the presence from your desk phone, mobile client, calendar, and other sources to be merged together to create a single presence status for a user.

Real-Life Example

To prove that I am not making this up, let’s take a look at a real-life example.  My company uses Avaya Aura for our communications and I have a 9641 SIP telephone on my desk.  I started traceSM (the Session Manager trace utility) and placed, answered, and released a call to my phone.  The following PUBLISH message was sent when I released the call.

Note the Content-Type of application/pidf+xml and the various XML elements that convey presence:

• status
• activities
• phonestate

Lit, Unlit, and Beyond

I hope this helps. I haven’t shown you all the possible element that might be sent in a presence update, but it’s not hard to imagine what they might be. The point is that a textual representation allows you to define presence to your heart’s content. Gone are the days of the two-state busy lamp. We are so much more than either lit or unlit.