(This is the first in a series of posts about MSRP, or the Message Session Relay Protocol.)

You’ve probably noticed several mentions of a messaging protocol known as MSRP in this blog. MSRP stands for the Message Session Relay Protocol (not manufacturer’s suggested retail price). MSRP was developed in the IETF by the SIMPLE working group. It’s documented in RFC 4975 and RFC 4976. The former describes the base protocol, and the latter describes the use of relays.

(Full Disclosure: I was the editor of RFC 4975. I am also a co-chair of SIMPLE–but not at the time the RFC was published.) 

SIP also has a built in mechanism for sending instant messages: the MESSAGE method. With the MESSAGE method, the content of an instant message is carried as the payload in a SIP message. That is, message content is carried as part of the signaling path, much like with SMS. Also like SMS, the MESSAGE method provides a “pager” like user experience, where there’s no inherent connection between one message and another. Client devices may simulate conversation threads, but there’s no concept of conversations in the protocol itself. And even more like SMS, the MESSAGE method also has some pretty strict limitations on the size of the content in a single message.

MSRP is a fundamentally richer approach, and differs from the MESSAGE method in several ways. The biggest difference is that MSRP uses a media session that is separate from the SIP signaling, similarly to how RTP is used for audio, video, or other real-time media sessions.  You use a SIP INVITE transaction, carrying an SDP Offer/Answer exchange to establish an MSRP session, and a SIP BYE request to terminate the session.

The explicit start and stop of an MSRP session makes it easier to provide “chat-room” style user experiences. A user enters a chat room with an INVITE request, and leaves it with a BYE. And the fact MSRP is treated much like any other media makes it easier to mix messaging sessions with other media streams. For example, you might have a video conference stream with an associated text conference stream. Floor control features could apply to both streams.

MSRP is inherently multi-media. It can carry any arbitrary type of content, and has no built-in size limitations. Even though it was originally designed with messaging in mind, it’s really a generic content transfer mechanism. For example, I’ve seen demonstrations of an MSRP-based mechanism for sending a photo to the person on the end of a pre-existing VoIP call.

MSRP clients can communicate directly, just like RTP clients. They can also use intermediaries called MSRP Relays. (Remember, that’s the “R” in MSRP.) The main point of MSRP relays is for firewall and NAT traversal. The relays can also be used for policy enforcement and for content-logging. MSRP allows devices to multiplex many MSRP sessions over a single TCP session, which allows a pair of adjacent relays between peering partners to minimize the number of TCP connections.

MSRP is a young protocol, as protocols go. It has not seen a lot of deployment yet–but that is starting to change. We’re starting to see some MSRP deployment by operators, along with some very innovative applications–one of which Adam Roach recently pointed out.

I’ve only scratched the surface of MSRP in this post. Next time, I’ll delve into how MSRP works with the SDP Offer/Answer model, and some SDP extensions that were required to make it work.

But before I sign off for today, I’ve got to get a rant in. (Surely the reader has come to expect a rant from me, yes?) Way back when we were putting the finishing touches on the MSRP RFCs, I was working in a shared office environment. The building had very thin walls (fortunately I’m in a much nicer space now). I overheard a rather loud person on the phone, talking about MSRP with quite a bit of energy. Wow, I thought–people were already using this! Only later did I realize he was talking about MSRP as the list price of something or another.

The moral of this story is, when you choose a name for a new protocol, go do a web search. If you find hundreds of unrelated hits, it’s a bad name choice. In the case of MSRP, I’m not to blame–I didn’t name it. But what can you expect from a work group named “SIMPLE”?

When I posted my Introduction to SIP-I and SIP-T back in May, I had no idea that it would become and remain our most-read blog posting. As there appears to be some interest in the topic, I plan to spend the next few months going over some of the areas in which SIP/PSTN deployment remains challenging.

This post deals with the difficulties that arise in the presence of overlapped dialing.

In countries that don’t have fixed-length dialing plans, it is common for the initial call setup message (IAM) not to contain a complete address for the called party. As the user enters more digits, they are sent in one or more subsequent address messages (SAMs), which are incrementally added to the address in the initial address message. This procedure is refered to as “overlapped dialing.” By contrast, SIP is designed so that the INVITE message contains a complete called party address. While this doesn’t cause any problems for calls originating in the SIP network, we need to add special processing in SIP to support overlapped dialing.

SIP-T and SIP-I both define a complicated procedure to handle overlapped dialing^[1][2]. Much of the complication arises from the different way ISUP handles overlapped dialing compared to the way SIP INVITE transactions are intended to operate. In ISUP, the originating switch sends digits until the remote exchange confirms that the address is complete (using an ACM). In SIP, incomplete addressing information is rejected with a special error code (484). In other words, ISUP uses a positive confirmation, while SIP uses a negative confirmation.

As a consequence, the egress gateway must decide when to reject INVITE transactions with incomplete addresses. For the sake of optimization, gateways are expected to be configured with a minimum address length for the terminating network. If the INVITE contains an address shorter than that minimum length, it can reject the request immediately as being incomplete.

After that minimum length is satisfied, the gateway must mediate between ISUP’s positive acknowledgements and SIP’s negative ones. This means that it must allow all of the INVITE transactions within a single dialing attempt to remain pending until it receives an ACM from the terminating network – then, it sends a 484 to all but the final transaction.

In a very simplified fashion, this looks something like the following call flow.

Even though this represents a single call attempt, it actually contains three (mostly) independent INVITE transactions. In this example, the IAM in message 1 contains fewer digits than the egress gateway is willing to accept. Messages 2, 3, and 4 represent the resulting INVITE transaction, which is immediately rejected by the egress gateway.

Message 5 includes additional dialed digits for the call attempt. The ingress gateway adds these digits to those already received in the IAM, and creates a completely new INVITE transaction with all the digits received so far (message 6). The total address length is now large enough that the egress gateway allows ISUP signaling to commence – it sends an IAM (message with the initial digits, and an SAM (message 9) with the additional digits.

Message 10 includes the final set of digits required to route the call. As before, the ingress gateway adds these to the digits already created, and creates a third SIP transaction. The egress gateway creates a SAM (message 13) containing the final digits, and sends it towards the terminating exchange. The PSTN indicates that digit collection is complete with an ACM (message 14).

The ACM tells the egress gateway that the most recent SIP transaction (the blue one) contains a full set of addressing information – and, by inference, that all previous transactions in this call attempt have incomplete addressing. The egress gateway terminates the other pending transaction (messages 15 and 16), and indicates that the remote terminal is ringing (messages 17 through 19).

In general, this works pretty well most of the time – except for the fact that it can tie up more SIP resources during the dialing phase than would otherwise be used. However, complications can arise when the SIP network is performing routing based on the called party number – or, worse, based on random distribution. In these cases, the INVITE messages associated with a single call attempt can end up routed to multiple gateways.

Egress gateways must be prepared to handle such circumstances by (1) freeing resources associated with a dial attempt after a reasonable timeout period, and (2) gracefully handling receipt of an INVITE containing SAM information, even if it never received the corresponding IAM. (Technically, this second problem never arises in SIP-T, since it requires overlap INVITEs to contain the IAM and all SAMs; however, SIP-I encapsulates only a single SAM in overlap-associated INVITE messages).

As a consequence of this routing issue, any SIP proxies involved in call routing will generally need to understand the overlapped dialing procedures and ensure that messages in a single call attempt are routed to the same destination.

There is an answer to the problem that avoids all of these headaches: running a digit collection timer at the ingress gateway. This is exactly what many international PSTN transgates do when transiting from, for example, North American callers to destinations with variable-length dial strings. However, most carriers reject this approach; while subscribers are accustomed to substantial call setup times for transatlantic calls, these kinds of delays are not likely to be acceptable for every day use.

[1] ITU-T Q.1912.5, Section 6.2

[2] RFC 3578

Last week I spent two days at MobiMedia 2009 in London. This is a small conference in which the latest developments in the academic world with regard to things like distributed video compression and novel wireless compression technologies are discussed. The part that I was involved with was a panel about the future of wireless multimedia services. The panel started with a presentation of a study done by Ofcom, the UK regulator, showing that under certain scenarios there will not be sufficient wireless spectrum available in 10 years. This was countered by researchers from the University of Edinborough and NTT docomo, who indicated that it is possible to increase the efficiency of the currently used spectrum not only by using even more efficient compression mechanisms but simply by using more intelligent bandwidth allocation schemes.

This discussion led somehow to the question of what mobile operators should be doing in order to make their subscribers’ lives more exciting in the future and finally to the question of whether IMS is dead, and if not, then why is it not deployed yet?

Thinking about this, IMS offers some good points. It enables mobile operators to continue using the same business model they are used to, namely providing telephony services and supporting roaming. Further, as operators can bundle the call establishment with guaranteed QoS they could offer qualitatively better services than VoIP providers who do not own a network. Also, the IMS architecture enables the operator to fulfill regulatory requirements with regard to emergency services and call interception in a rather straight forward manner. Finally, bundling voice services with other services should be easier in an all-IP environment thereby enabling the operator to offer a million new exciting and revenuegenerating services. But, all of these points could be achieved in a simpler manner.

With all of these positive points, one can only wonder why operators are not tearing up their SS7 infrastructures and are not spending billions on IMS solutions -which would have as a side effect that thousands of jobs would be saved, the economy would prosper, the stock market would soar and with every one becoming prosperous, world peace would finally become a reality.

 If we leave aside the usual ranting about the complexity of IMS and how it undermines the open concept of the Internet and reintroduces the closed-wall garden model, I would say that IMS at this stage is still a bit too early. In order to be able to fulfill the promise of IMS, namely more services and the integration of voice, video, text, presence and web applications, a mobile operator will need two important components which are not available today; namely high bandwidth wireless access and end devices that are designed to offer more than telephony services.

Using VoIP over wireless networks is in general less efficient than using the circuit switched technology we have today. The mobile phones available today are designed to offer telephony services. Hence, even if an operator started offering some IP-based services, the number of people who would benefit from these services would be limited.

So is this final verdict?

Well I am not sure. With the mobile operators moving to LTE with a simplified all-IP network and much higher wireless access bandwidth, I would not be surprised if IMS becomes all the rage again. Regardless of all of its shortcomings, IMS or at least SIP-based signaling is still the only viable alternative to SS7. So if mobile operators see themselves as providers of telephony services and not just bit-pipes, then IMS will most likely be their first choice as an IP-based signaling infrastructure.  On the other hand, with high access speeds there is no need to worry about QoS so one of the alleged advantages of IMS would disappear as well.

With regard to the end devices, we have seen in the last one to two years an increasing number of phones that are powerful enough to support a wide range of multimedia and web applications as well as being easy to use. However, any application that can be built on top of IMS can be provided over a much simpler SIP infrastructure as well.

With this in mind, I am still hopeful that one day my mobile phone will truly be a an IP-device offering integrated voice, video and web applications (whatever this means .

When thinking of denial of service (DoS) attacks we usually have the picture of a mean hacker wanting to fight capitalism, prove his superior technical knowledge or simply for money.

Unlike attacks launched by malicious hackers, unintentional attacks are not launched on purpose but still have the same effects; namely, reducing the availability of the service. Such attacks can in general be explained by bad design of a system or implementation or configuration mistakes. Unfortunately, while there has been a lot of talk about intentional DoS attacks, most of the problems we have seen in the real world can be classified as unintentional.

Flash Crowds

Flash crowds indicate cases when a lot of users request the same service at nearly the same time. This is often observed in traditional telephony networks when TV viewers are asked to vote on a certain event, for example.

The first of such an attack in the Internet was related to the distribution of the “hosts.txt” was used for mapping of host names to IP addresses. Hence, whenever a new host was introduced to the Internet, this file was updated. For the other hosts to be able to contact this new host, they update their local version of the hosts.txt file. This meant that regularly, e.g., whenever a new version of the hosts.txt file was announced, an increasing number of hosts were downloading this file. With each addition of a new host the number of hosts downloading this file was increasing and hence increasing the load on the server managing this file. The introduction of the domain name system (DNS) successfully prevented this kind of attack and allowed the Internet to scale up to its current size of millions of hosts.

Another form of flash crowds is today known as the Slashdot effect. The Slashdot effect is the term given to the phenomenon of a popular website, e.g., slashdot, linking to a smaller site, causing a huge influx of web traffic to be directed to that site. This sudden increase in traffic causes the smaller site to slow down or even temporarily close.

Implementation and Configuration Mistakes Due to misinterpretation of the standards or plain mis-configuration of devices might result in the sending of a high volume of requests that overload servers. Clayton¹ lists a number of such examples in which some applications or access devices generated hundreds of thousands of NTP (Network Time Protocol) requests in a matter of seconds. This has caused the NTP servers to be overloaded leading to a high delay in their reaction to legitimate requests and to an overall reduction in performance of all devices and hosts that depend on these servers. Similar scenarios were observed with DNS as well.

In terms of SIP, we have observed different unintentional attacks in the last years. One of the most famous ones we call the midnight attack. In order to prevent users of private DSL links from providing public services, the provider of the DSL service requires that the DSL line of its private users is reset once a day. In order to make sure that the users of the VoIP service of this operator are always registered, the vendor of the IAD devices that implement the DSL connection and the SIP user agent implemented his devices in such a way that they are reset every 24 hours as well. So at some point after midnight, all the devices of this vendor reset themselves at more or less the same time. With nearly a million devices resetting their DSL line and reregistering with the SIP infrastructure the operator’s VoIP and DSL service was overloaded and became unavailable for a period of time.

On another occasion we observed a dramatic increase in the number of registrations. This was unfortunately not due to an increase in the number of subscribers but because of a mistake in the implementation of a certain type of SIP user agents. These user agents were sending registration requests, authenticating themselves and as soon as they receive the 200 OK they send a new registration request. After analyzing the problem we discovered that a certain vendor was causing the problem. As the problematic user agent was a widely used one, simply filtering out all REGISTER requests from this user agent would have meant that a large portion of the VoIP service’s subscribers would be unreachable.

Combating unintentional attacks is rather difficult as the operator of the attacked server can only see that the load on the server has increased but not why. The generated traffic is usually legitimate and needed albeit not at the generated rate. Faulty devices and applications can be identified as those that generate traffic at a higher rate than they are supposed to. Identifying the source IP addresses of these devices and applications and dropping all traffic from them reduces the load on the affected servers. However, this means that legitimate users that are using these devices and applications are blocked as well. In case the fault is common to a popular device or application that is used by a lot of users, then simple blocking would affect a large part of a provider’s subscriber base. This would most likely lead to an increase in the number of calls to the support centers and a lot of bad publicity to the provider.

Reference:

1. Clayton R 2006 The rising tide: DDOS from defective designs and defaults. SRUTI’06: Proceedings of the 2nd Conference on Steps to Reducing Unwanted Traffic on the Internet, 1. USENIX Association, Berkeley, CA.

An html version of the SIP Pocket Guide is now available on tekelec.com. Click HERE to access the reference guide.

Online SIP Reference Guide

There is a twist to the way SIP URIs are compared that surprises many implementors and operators when they discover it. It’s called out explicitly in RFC3261, but it is non-intuitive enough to continue to trip people up.

Most people take transitivity of equality for granted. If A and B are the same, and B and C are the same, then it must be the case that A and C are the same, right?

Not so with SIP URIs. To understand why, let’s look at how SIP URIs are formed:

A SIP URI starts out with the scheme “sip”, followed by an optional username, a mandatory host (which may be a literal IP address), an optional explicit port and optional parameters and embedded header fields. This allows SIP URIs to be as simple as:

sip:RjS@tekelec.com or perhaps sip:line1@192.168.0.1

or as complicated as the one in the anatomical diagram above.

When SIP URIs are compared, some fields are compared case-sensitive, others are compared case-insensitive, some characters can be encoded multiple ways (escaped using the “% hex  hex”  notation you see above), and others can’t. Some fields have default values. Some have default values only in certain circumstances (the default port of 5060, for example, is only assumed if the URI specifies the transport without using DNS). The number of details here is large, and I’m not going to dive into all of them – see RFC3261 section 19.1.4 if you want to explore them. What I hope I’ve conveyed is that comparing SIP URIs is complicated. It may be the hardest thing to fully implement in SIP.

Among those details are two that interact to bring about the surprising result this article is focusing on:

1. unknown parameters are ignored for comparison if they only appear in one URI
2. unknown parameters that appear in both URIs are included in the comparison

“Unknown” in the above rules refers to those parameters that an implementation hasn’t been programmed to recognize. This rule was added to allow new parameters to be specified and introduced into networks in a way that would be backward-compatible with running implementations that hadn’t been told what to do with those parameters yet.

At the moment, “blog”, “parakeet”, and “security” are examples of parameter names that have no standard meaning and will be treated as unknown parameters by most, if not all, implementations currently in the field. For the purposes of this example, I’m going to use “security”.

Consider these two SIP URIs:

sip:RjS@tekelec.com;lr and sip:RjS@tekelec.com;lr;security=off

‘lr’ is a standard parameter defined in RFC 3261 indicating loose-routing. Since it is a “known” parameter, it gets included when we compare the URIs. ‘security’, on the other hand, is an unknown parameter, so it is not used when we make the comparison. Thus, the URIs are equal.

We could reorder the parameters without changing equality. The following three URIs are all equal to each other:

• sip:RjS@tekelec.com;lr
• sip:RjS@tekelec.com;lr;security=off
• sip:RjS@tekelec.com;security=off;lr

Likewise, these would all be equal if we changed all of the values from “off” to “on” (or any other value). And that leads us to the surprise:

These are equal:

• sip:RjS@tekelec.com;lr;security=off  (call this A)
• sip:RjS@tekelec.com;lr (call this B)

And these are equal

• sip:RjS@tekelec.com;lr (this is B again)
• sip:RjS@tekelec.com;lr;security=on (call this one C).

So we have A=B and B=C, but these two are not equal

• sip:RjS@tekelec.com;lr;security=off (A)
• sip:RjS@tekelec.com;lr;security=on (C)

When an unknown parameter appears in both URIs, it is included in the comparison. The decision to include that rule was heavily debated as the standards were being forged. The prevailing thought was that it would allow the rendezvous service at proxy/registrars to “do the right thing” with request-URIs and registered contacts containing parameters they didn’t know about, simplifying rolling out new services. 

So, how does this trip operators up?

It’s very easy to let the assumption that A=B, B=C implies A=C to get coded into applications as part of routing logic or even authorization. You’ve checked that a request-URI matches a subscriber’s Address-of-Record (AoR), and you’ve checked that the AoR matches some application URI (like one in a presence document’s “entity” field, or one in a P-Asserted-Identity header field), so you assume the request-URI matches the application URI without checking and the application does something you didn’t expect.

It’s a difficult pitfall to spot. Hopefully this SIP FAQ posting will help you avoid it.