Rummaging Through the SIP Closet
I have a difficult time throwing things out.
Perhaps it’s due to my optimistic nature, but I always feel that no matter how long something has sat around unused, there is a good chance that it will prove useful sometime in the near future.
Just take a look at my dresser drawers and closets. They’re filled with shirts, pants, coats, suits, and ties that I haven’t worn in years. Some are practically threadbare and some show little signs of wear. The condition isn’t even a deciding factor, though.
I keep things because, well, just because I keep things.
SIP has a little of that, too. While it hasn’t been around as long as some of the t-shirts I own (I am not kidding), there are a few relics that deserve a second look.
This article originally appeared on SIP Adventures and is reprinted with permission.
For the next few minutes let’s take a journey through the closet of SIP and see what, if anything, can be tossed or at least donated to the Goodwill.
As you know, headers are used to identify the characteristics of a session.
For instance, To indicates the destination of a session and From identifies the creator.
There are many more headers that you see on a regular basis in both requests and responses. However, there are several headers that in all my years of SIP programming and Wireshark traces, I’ve never come across.
So, in no particular order, let’s take a look at a few of them.
Related article: Wow, I Can Do That with Unified Communications?
The first on my list is Subject. Like the subject of an email, this header can be used to provide a brief reason as to why the session exists. For example, I might tag a phone call as “lunch” if I were calling to invite a coworker out for a quick bite.
A few weeks ago, I wrote about providing the context of a call in my article Contextual Communications. Subject would be perfect for that.
You might want to answer the call tagged with the subject “Quarterly sales numbers” over the one labeled “My vacation to Akron” — or vice versa. A little extra context to phone calls would go a long way in terms of prioritizing your day.
Subject: I am calling about today’s meeting
However, as cool as having a subject associated with a phone call is, I have never actually seen it implemented. There is nothing on any of my hard, soft, or mobile SIP phones that allows me to enter a subject. Even if such a parameter existed, none of my devices have a designated spot to display it.
A perfectly good header that provides a very cool feature sits unused.
I can say the same thing about the Priority header. Similar to an email priority flag, you can set different levels of session priority. So, instead of just a subject that says “Quarterly sales number,” you could also tag it as “High Priority.” This adds even more context to another otherwise uncategorized call.
Sadly, I have never seen the Priority header used, either. Would I love to click a priority flag on an outgoing call? You bet I would. I would love the recipient to know when he or she can safely ignore my call or when it absolutely needs to be answered.
There are a few more headers that fall into the “defined, but I have never seen” camp. I can find uses for the Alert-Info and Organization headers, but sadly, I’ve never seen a SIP device that supports either one.
Next are the Response codes.
As with a few SIP headers, there are response codes that I’ve never come across in all my dealings with SIP. It’s not that I think they shouldn’t exist. I just can’t seem to find anyone who has actually implemented them.
We should all be familiar with a 200 Ok response. You send or receive one of those every time a call is answered. (If you read my article, REFER Revisited, you should also understand 202 Accepted).
Who out there is familiar with the 204 No Notification response?
The SIP specification says that this response indicates that “the request was successful, but the corresponding response will not be received.” Huh? I’ve poked around the Internet and found a document that says it will only be sent after a SUBSCRIBE, but it was completely vague as to when and why. It might have a wonderful use, but until I find a better explanation, it goes into my “Why is this here?” pile.
I am sure that some of my readers have their own list of unused, little used, or “huh” aspects of SIP.
However, like my drawers filled with old race t-shirts, I expect that that they will be around for quite some time. After all, you never know when you just might need something.
If you’re like me, it’s probably a couple days after it has been tossed out.
Understanding SIP PRACK for Avaya Aura
As many of my readers know, every few months I teach a two and a half day class on “all things SIP.” My students are exposed to everything from “why SIP” to the nitty-gritty of SIP requests, responses and call flows. I even speak about some of the more esoteric topics such as To and From tags, the Replaces header, nonce values and TR-87.
Included in the esoteric list is the PRACK (Provisional Response Acknowledgement) method. PRACK wasn’t in the original SIP specification and was introduced later in RFC 3262. It came about after it was realized that some user agent servers need to know that a provisional response was received by a user agent client. Before PRACK, 1xx responses sent using UDP might get lost, and the sender would never know. PRACK adds a layer of reliability to an otherwise unreliable call flow.
I previously addressed PRACK in my article “Ducks Go Quack. SIP Goes PRACK.” Although I addressed most of the pertinent material, I was short on examples and real-life call flows. As I walked my most recent students through live calls on my company’s Avaya system, I happened to notice a few PRACKs and decided it was time to update my old article.
The following screenshots were gathered using the Avaya traceSM utility. I simply started traceSM on a live Aura system, let it run for a few minutes, and then stopped it after I noticed a few PRACK messages fly by. This was simply because I was unsure as to when Avaya uses PRACKs and when it does not. In other words, “When in doubt, trace it out.”
Let’s start at the beginning. PRACK messages aren’t just sent out-of-the blue. The sender of an INVITE message must indicate that it is capable of sending PRACKS. It does that by including the header in the INVITE message:
This tells the recipient that, if requested, it will send PRACK messages for 1xx Responses.
The following shows an INVITE with such a header.
Now that the user agent server knows that PRACK messages are possible, it will include headers similar to the following in all 1xx Responses it wants to be PRACKed:
The Requires header with a value of 100Rel tells the user agent client (the sender of the INVITE) that a PRACK is expected for this response. It’s important to know that the user agent server (the sender of the Response messages) has to request the PRACK. It’s not an automatic process and must be initiated with an Rseq header.
The value in Rseq is used by the user agent client when it creates a PRACK message. The user agent server is responsible for setting and incrementing this number.
The following 180 Ringing indicates that it expects a PRACK.
Upon receipt of this 180 Ringing, the user agent client must respond with a PRACK message. Of interest to this article is the Rack header. This header must contain the Rseq value sent in the previous 180 Ringing. Additionally, it will indicate the original INVITE session’s CSeq number. Look back at the INVITE in this call flow, and you will see a CSeq value of 1 (one). Therefore, the Rack will look as follows:
Rack: 1 1 INVITE
Next, the user agent server will send a 200 Ok for the PRACK. This tells the user agent client that the PRACK was received and processed.
For grins, I will now show you the 200 Ok for the original INVITE. Note that it does not have a Rseq header and 100Rel is not in the Requires header. Why not? That’s because this is not a provisional response. PRACKs are only sent for 1xx responses.
Before I close things out, I want to address the question I hinted at near the top of this article. When does Avaya use PRACK?
While I honestly don’t know all the permutations, it appears that an INVITE from an Avaya endpoint will always indicate that it supports PRACK (Supported: 100Rel). However, as you just learned, it’s the recipient of the INVITE that indicates if PRACK messages are required.
In the example above, the Avaya Modular Message voice mail server requests PRACK messages. Additionally, PRACK is used when direct media is enabled.
There is a good chance that PRACK is used in other situations, but I am going to have to start up a few more traceSM sessions to learn where they show up.
That’s about all I really need to say about PRACK. I invite you to take a look at the RFC if you want to learn about any PRACK subtleties I might have missed, but for all practical purposes, I’ve said all that needs to be said. I hope you had as much fun today as I did. As is often the case, I learned something in the process of writing this article, and that’s always a good thing.
Understanding Avaya Aura SIP Registration
“Let’s start at the very beginning/a very good place to start/when you read you begin with A B C/when you sing you begin with Do Re Mi.”
I have always loved musicals, and Rogers and Hammerstein’s “The Sound of Music” is high on my list of favorites. Sure, it’s corny and far from historically accurate, but that doesn’t bother me in the least. I’m always willing to set aside any sense of reality for good singing, romance and adventure, and “The Sound of Music” has them all.
So … what does this have to do with unified communications? REGISTER, of course. Like Do Re Mi, you begin SIP with REGISTER.
This article is a continuation of the concepts I presented in A Close Look at Avaya Aura IMS Call Processing and An Even Closer Look at Avaya Aura IMS Call Processing, and I’d suggest you take a look at those before tackling this one.
Can you get SIP devices to communicate without REGISTER? Absolutely. In fact, when I teach my SIP class, the students put their SIP clients into point-to-point mode, which does not require REGISTER. This means that clients send SIP requests and responses directly to the other clients, not through a proxy. The clients can do everything all by themselves.
However, point-to-point without REGISTER has a serious downfall. The clients are required to know the IP addresses of all the other clients they wish to communicate with. While this is fine in a limited classroom environment, it becomes unwieldy after you grow beyond a handful of endpoints.
As an analogy, imagine having to know the IP address of everyone you wanted to send an email to. That’s the same problem you have if you don’t use REGISTER. It’s simply not practical.
The Tie that Binds
REGISTER associates a user’s identification, or Address of Record (AOR), with one or more locations. Note that I said locations. You are not limited to registering an AOR to a single device. Personally, I routinely register my AOR to a physical desk phone and multiple SIP soft-clients. Avaya Aura supports up to ten such registrations per user. That’s enough to make even the most device-crazy nerd happy.
You bind an AOR to an IP address with a Contact header. For example, one of my soft clients might tell a SIP registrar that aprokop can be reached at 192.168.0.14 with this Contact header.
Contact: Andrew Prokop <SIP:email@example.com>
Registrations are time-based and will eventually expire. This requires the client to periodically refresh a REGISTER with a new REGISTER. Actually, new isn’t the correct word to use for this. Subsequent REGISTER messages must contain the same Contact, To, From, call-ID and From Tag as the original registration. This allows the SIP registrar to know that it’s simply a refresh and not a new registration for the same AOR.
Note that CSeq will increment with each REGISTER sent.
Keeping Things Secure
I might tell my communications system that I am Andrew Prokop, but it would be foolish to trust me at face value. That’s why SIP allows a REGISTER to be challenged.
Before I go through a REGISTER challenge, allow me to define something known as a nonce.
Nonce stands for Number Once and is an arbitrary number used only once in a cryptographic communication. The recipient of a nonce will use it to encrypt his or her credentials. Number Once refers to the fact that encryption with this nonce can only be done one time. If someone were to sniff the LAN and obtain someone’s encrypted password, it won’t do them any good because it can only be used in a single transaction. It becomes stale and useless immediately after its first use.
A REGISTER flow is fairly simple and follows these steps:
- A user sends a REGISTER to the SIP registrar. For Avaya Aura, this is a Session Manager. The To and From headers contain the user’s AOR. The user specifies the number of seconds the registration should be valid in the Expires header. This value can be later raised or lowered by the registrar.
- The registrar returns a 401 Unauthorized response with a WWW-Authenticate header. This header contains data that must be used to encrypt the user’s communications password. Specifically, it contains a nonce along with the name of the encryption algorithm that the client must use.
- The user sends a second REGISTER to the SIP registrar. This REGISTER contains an Authorization header. Within Authorization is the user’s encrypted password.
- If the correct password is received by the registrar, a 200 Ok response is sent to signify a successful registration. An Expires header may be present with a different value than what the user requested. This is the time the registration will be valid as determined by the registrar’s policies.
A registration is removed by sending a REGISTER with an Expires header value of 0 (zero).
In a picture, we have this.
Using the traceSM tool on an Avaya Aura Session Manager, I captured the following trace that shows a REGISTER, the challenge and a REGISTER with encrypted credentials. Take a look at the headers, and you’ll see that they’re doing exactly what I said they would do.
In the case of my daily work life, my various SIP devices will each send a REGISTER, be challenged and resend the REGISTER with the encrypted credentials. They periodically refresh their registrations to ensure that I am able to make and receive calls on all my devices until I am finished for the day.
Speaking of finished for the day, that’s about all I have to say about REGISTER. It’s not that complicated once you understand the basics. Just keep in mind that while registration isn’t absolutely mandatory, it enables a secure, scalable and easy to manage SIP solution.
… And these are a few of my favorite things!
Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.
Learning to Work With Avaya Aura Session Manager Adaptations
The problem with standards is that they rarely are. Despite the fact that SIP has been around since the 1990s, is fairly well documented, and exists inside solutions from a variety of providers, there are still far too many situations where one vendor’s SIP has trouble speaking with another vendor’s SIP. Solution X might use the History-Info header while Solution Y is looking for the data in the Diversion header. Company A might love to use multipart MIME in their SIP message bodies—causing Company B’s softphone to go belly up.
In addition to these protocol mismatches, there are times when you need to reach into a SIP message and change the data. For instance, there may be instances where you need to change the domain in the FROM to something other than what the SIP client set it to.
This is where SIP adaptation comes in. Adaptation is the process of altering SIP packets to make the recipient see messages as they want (or need) to see them. Perhaps it’s as simple as the aforementioned domain name change, but it might be as complicated as adding new headers or removing existing ones.
If your Session Manager programming is a little rusty, you may want to start here: An Avaya Aura Session Manager Cookbook.
Adaptation is typically done by a SIP proxy that sits between two or more SIP endpoints. One such proxy is the Avaya Aura Session Manager (SM). As part of the process of creating routing rules for SIP messages, administrators define adaptations that are applied on the ingress and egress sides of SIP entities. SIP entities can be Avaya Communication Managers, Session Border Controllers, other SIP communications servers (CS1000, Cisco Call Manager, etc.) or a myriad of other forms of SIP servers.
Creating SM adaptations can range from very simple to extremely complex. The easiest adaptations are the ones that use the built-in modules that Avaya supplies and basic digit conversions. The most challenging adaptations require sophisticated SIP header manipulations and complex digit conversions. Thankfully, the tools that the Avaya Aura System Manager (SMGR) provides greatly simplifies the creation of both types.
To create an adaptation, log into SMGR and navigate to Home > Elements > Routing > Adaptations.
From this screen, press New to bring up a template to create your adaptation.
Name the adaptation and choose a Module Name. The Module Name dropdown list contains all the built-in Avaya adaptations. These include:
Several of these are fairly obvious. For example, if you are sending to and receiving from a Modular Messaging server, chose ModularMessagingAdapter. Others are less obvious and should only be used when instructed to by DevConnect implementation notes.
The most common adapter is DigitConversionAdapter, and unless instructed otherwise, it is the one you will typically use. This adapter allows you to manipulate digits (i.e. telephone numbers) that are sent to (ingress) SM and from (egress) SM. For example, if you are routing calls to an Avaya Communication Manager, you would choose DigitConversionAdapter.
Note that no matter what adapter module type you choose, you still have the ability to perform digit manipulation. In other words, an adapter such as CS1000Adapter allows you to perform CS1000-specific adaptations, as well as those provided by DigitConversionAdapter.
Next, you have the option of performing header manipulation on incoming and outgoing SIP messages. There are two ways of doing this, but one of those ways is a subset of the other and essentially unnecessary.
If SIP header manipulation is required, my preference is to always choose Name-Value Parameter from the Module Parameter Type dropdown. This allows you to create parameter/value tuples that direct SM to perform specific SIP header manipulation operations.
The choices for parameter types differ greatly between Aura version 7.0 and pre-7.0. Pre 7.0 gives you a few basic choices, while 7.0 greatly enhances your options.
I’ll start with Pre 7.0, but rather than trying to reproduce the list of choices, I will simply cut and paste from the Avaya documentation and help files.
Pre Aura 7.0
Supported adaptation module parameters are:
- fromto: if set to true, the adaptation modifies the FROM and TO headers of the message. If omitted or set to any other value, FROM and TO headers will not be modified.
- multipartMIMEsupported (can be abbreviated to MIME): (Optional): This adaptation applies to the egress processing only. If the parameter is present and set to no, then multipart MIME message bodies will be stripped on egress from Session Manager. If the multipart MIME message contains an SDP message body, it will be inserted as the only message body in the outgoing message. If omitted or set to any other value, message bodies will not be modified.
EGRESS Domain Modification Parameters:
- overrideDestinationDomain (can be abbreviated to odstd): replaces the domain in REQUEST-URI, TO header (if administered), REFER-TO header, and NOTIFY/message-summary body with the given value for egress only.
- overrideSourceDomain ( can be abbreviated to osrcd): replaces the domain in the FROM header (if administered), P-ASSERTED-IDENTITY header and calling part of the HISTORY-INFO header with the given value for egress only.
INGRESS Domain Modification Parameters:
- ingressOverrideDestinationDomain (can be abbreviated to iodstd): replaces the domain in REQUEST-URI, TO header (if administered), and NOTIFY/message-summary body with the given value for ingress only.
- ingressOverrideSourceDomain (can be abbreviated to iosrcd): replaces the domain in the FROM header (if administered), P-ASSERTED-IDENTITY header and calling part of the HISTORY-INFO header with the given value for ingress only.
EGRESS Display Name Modification:
- egressDisplayName: In Session Manager 6.3.4 and later, the adaptation module modifies the display name of the CONTACT, P-ASSERTED-IDENTITY, and FROM/TO headers (if fromto = true).
For outgoing calls, adaptation is applied to the P-ASSERTED-IDENTITY, CONTACT, and FROM headers in both the initial dialog-creating request sent from the Session Manager and in all subsequent in-dialog requests.
For incoming calls, adaptation is applied to the P-ASSERTED-IDENTITY, CONTACT, and TO headers. If the value of the parameter contains spaces, the value must be enclosed in double quotes. Additionally, any double quotes that are part of the parameter value must be preceded by a backslash character.
Example values for the egressDisplayName parameter are:
- egressDisplayName=”My Business”
- egressDisplayName=”The \”Best\” Business”
The following screenshot demonstrates a set of parameters and values that instructs SM to change the domain name within outgoing calls to mydomain.com. Since fromto is set to true, this includes the REQUEST-URI, TO header, REFER-TO header, and any NOTIFY/message-summary body.
Aura 7.0 allows you to use all of the previous options, plus quite a few new ones. As you will immediately see, 7.0 adaptations are much more flexible than those possible in previous releases. Again, this is almost a straight copy from the Avaya documentation.
- adaptForeignURI: If the value is set to true, the ingress adaptation is applied to the Request-URI and the TO header (if fromto is set to true), even if the host part is an IP address that is different from the IP address of the Session Manager.
- noidtmf: If the value is set to true, no DTMF message body conversion is performed on ingress.
- dtmf: The value of this parameter determines the DTMF message body format that is desired on egress from the Session Manager. If omitted, no conversion is done. Supported values are nortel, relay, and dtmf.
- keepPortTransport: If this parameter is present and set to any value, Session Manager does not strip the port and transport when the domain of the Request-URI is modified on egress.
- noar: This parameter requires a comma-separated list of SIP response codes. This parameter is applicable to the egress adaptation only. You can use this parameter to override the default alternate routing behavior of Session Manager. Session Manager does not alternate route a request to the next SIP Entity if it receives one of the responses listed in the parameter value.
An example of a comma-separated list is noar = 404,486.
- sessionTimeout: Use this parameter for SIP entities that do not support the session timer, as per RFC 4028, or to send periodic SIP messages to keep the session active for more than one hour. If both entities use the session timer in a call, Session Manager keeps the session active for the negotiated interval. If the entities do not use the session timer in a call, then Session Manager keeps the session active for one hour after the last SIP transaction. In such cases, you can set this parameter (in seconds) to extend the one hour interval. For example, if the session timer is not used, the parameter value of sessionTimeout=7200 makes the session stay in memory for 7200 seconds (120 minutes) after the last SIP message exchange.
- noallow: This parameter requires a comma-separated list of SIP methods. The system strips the methods from the Allow header on egress. Method names are case-insensitive. For example, noallow=UPDATE and noallow=UPDATE, OPTIONS.
- iRhdrs: Removes the specified header or headers during adaptation process from messages in the ingress direction. Separate multiple headers with a comma. For example, P-Charging-Vector, P-Location. Header names are case-insensitive. The administrator can remove the headers that Session Manager may add during post adaptation module invocation, for example, P-Location.
- eRhdrs: Removes the specified header or headers during adaptation process from messages in the egress direction. Separate multiple headers with a comma. For example, P-Charging-Vector, P-Location. The administrator can remove the headers that Session Manager may add during post adaptation module invocation, for example, P-Location.
- reduceRtHdrs: Intermediate Aura elements add routing headers when SIP messages move from one element to another. To reduce the number of routing headers values from the SIP message, use the reduceRtHdrs parameter.
If reduceRtHdrs is set to true, the system reduces the number of routing headers values, such as Via and Record-Route from SIP messages. However, all the outgoing messages from Session Manager will have the Via and Record-Route header with values of Session Manager IP and transport. This ensures that all the subsequent responses and requests for that call will be delivered back to Session Manager.
Digit manipulation allows you to define rules that change telephone numbers as they enter and leave SM. This requires you to understand the specific requirements of the SIP entity the adaptation is applied to.
In general, I like to ensure that all numbers entering SM are converted to an E.164 format. This includes the +1 prefix.
For calls to Communication Manager, I convert numbers to E.164 without the + sign.
The following graphic shows a simplified view of that conversion:
When you’ve finished with an adaptation, apply it to the appropriate SIP Entity in Home > Routing > SIP Entities.
That was a lot of information, but I hope you found it useful. As a purist, I wish that the need for adaptation went away, but as a realist, I know that that’s probably never going to happen. Until then, the tools that System Manager provides allow you to seamlessly connect all kinds of SIP servers and be reasonably assured that they will happily coexist.
For more information, visit Andrew Prokop’s blog, SIP Adventures.