My last post described the MSRP Session Match extension (aka “sessmatch”) and its purpose. I mentioned that there were some backwards compatibility issues. This week I will discuss those issues in more detail.

The session matching criteria in sessmatch were intended to be backwards compatible with RFC 4975. Remember, sessmatch relaxes the session matching rules so that only the “session identifier” component of an MSRP URI is considered when matching an MSRP request to a session. An MSRP URI that matches a session according RFC 4975 (that is, an as an exact URI match) always also matches according to sessmatch. And as long as nothing modified an MSRP URI in the SDP offer and answer, then things will still match according to RFC 4975 rules.

But keep in mind that the whole point of sessmatch is to allow a device, for example an SBC, to modify the MSRP URIs in the SDP. So I think we can assume that, whenever sessmatch is used, something probably does modify the URIs.

As sessmatch was specified prior to version 11 of the draft, An MSRP endpoint that supports sessmatch, and is also behind an SBC, cannot talk to an endpoint that does not support sessmatch.

And even if both endpoints support sessmatch, things break down if one endpoint uses an SBC and the other uses an MSRP Relay. The sessmatch extension, as currently written, does not apply to MSRP relays. But relays use the same session matching rules as in RFC 4975. So if an SBC modifies the offer or answer, then the session will fail to match at the relay.

That problem could be mitigated if we extended sessmatch to apply to relays as well. But there’s still a more subtle problem. One very popular feature of SBCs is something called “topology hiding.” Topology hiding means that the SBC hides artifacts (such as IP addresses, host names, and URIs) that identify hosts on one side of the SBC from devices on the other side. This is done for a variety of reasons. Some providers believe their internal topology to be sensitive information. Some want to anonymize the IP addresses of their customers.

Topology hiding can be applied in any number of places. For example, it’s common to hide SIP Route, Record-Route, and Via header field values. But if an SBC performs topology hiding on SDP payloads, then MSRP relays will break.

An endpoint that uses an MSRP relay puts the entire MSRP path to the endpoint in its SDP path attribute. This may look something like the following:

a=path:msrp://relay.example.com:2855/asfd34;tcp msrp://bob.example.com:3464/siefkd938;tcp

MSRP Relays are session-stateless. They need this entire path in order to figure out where to route MSRP messages. But if a topology hiding SBC removes part of that path, the relay can’t deliver inbound messages. For example, the SBC might change the previous path attribute to look like this:

a=path:msrp://sbc.example.com:2855/asfd34;tcp 

Now when Bob’s peer tries to send an MSRP SEND request, it will probably get as far as Bob’s relay. But the relay will have no idea how to send it on to Bob.

Version 11 of the sessmatch draft recognizes the backward compatibility issues and proposes a new SIP option tag that indicates an endpoint both supports and is deployed in a way that it can actually use the sessmatch extension. This will at least allow endpoints to fail in a graceful way if their network policies prevent them from exchanging MSRP messages. In the best case, the endpoint behind the SBC could attempt to use an MSRP relay instead, or an SBC could change its behavior for the session to avoid incompatibilities. But in reality, providers that use an SBC in the first place are unlikely to allow such fallbacks as a matter of policy.

The option tag will help prevent the balkanization of the MSRP protocol itself. Unfortunately, the need for sessmatch in the first place shows that service providers, through incompatible policies and network designs, are likely to break the MSRP user communities into islands that can’t talk to each other.

As I and others on this blog have mentioned on several occasions, the SIMPLE (or the more formal and rather awkward: “SIP for Instant Messaging and Presence Leveraging Extensions”) working group of the IETF has been responsible for defining how to do Presence and Instant Messaging applications using SIP and related protocols. The SIMPLE working group has existed for some time; in fact, it’s one of the oldest ongoing working groups in the Real-time Applications and Infrastructure (RAI) area of the IETF. I am currently a co-chair for SIMPLE.

I write to tell you that SIMPLE’s work is almost done. We are finally seeing the light at the end of this long tunnel. Of the four remaining work items, one is in the AUTH48 state. (This means that the RFC editor has presented a candidate for the final RFC version back to the authors for any last minute edits and approval.) One entered Working Group Last Call (WGLC) last week. There are only two work items that may still see controversy, and one of those is in IESG review.

These drafts are, respectively, draft-ietf-simple-msrp-acm, draft-ietf-simple-simple, draft-ietf-simple-msrp-sessmatch, and draft-ietf-simple-chat.

The first draft extends the MSRP protocol to allow the endpoints to negotiate which one will open a TCP connection to its peer. I blogged about this draft some time ago. We should see publication of the resulting RFC any day now. In fact, it’s already been assigned a number: RFC 6135. [Update: RFC 6135 was officially published on February 28.]

The second, draft-ietf-simple-simple (aka “SIMPLE made Simple”), is an informational draft that acts as a road-map and secret-decoder-ring for the various specifications produced by the SIMPLE working group. (Keep in mind, that there is no one protocol known as SIMPLE. But we still tend to use the term SIMPLE informally to refer to the resulting suite of protocols and architecture.) The fact that this draft is in WGLC means the author believes that this draft is essentially ready to be sent to the IESG for final review and publication. It’s possible that the last call review could uncover some controversial point that would require more work. But given the nature of this draft, I expect that any WGLC feedback is more likely be clarification and editorial comments.

We do know in advance, however, that draft-ietf-simple-simple may require minor editing to reflect the final disposition of the last two drafts below. This means that, regardless of its current completion state, draft-ietf-simple-simple will be the last draft to be published by SIMPLE.

Draft-ietf-simple-msrp-sessmatch describes an extension to MSRP to make it more friendly to Session Border Controllers (SBCs). The way that MSRP devices match TCP connections to message sessions means that, if an MSRP session traverses an SBC, that SBC has to re-write the To-Path and From-Path header fields in a manner similar to an MSRP Relay. Some working group participants expressed concern that this requirement could impact SBC performance. The sessmatch draft would allow supporting endpoints to work across SBCs that do not change MSRP messages en route. However, there are still ongoing discussions concerning the impact on security and interoperability.

Assuming that the sessmatch draft has not become a moot point by then, I plan to go into considerably more detail on it and the surrounding controversy in my next blog entry.

Then, finally, there’s draft-ietf-simple-chat. This draft defines how to create MSRP “chatrooms” with conference servers. There’s still some controversy over how this draft interacts with some similar work from the XCON working group.

Hopefully, we will resolve the issues around these last two drafts soon–at which time I hope to be able to entitle a blog entry as “SIMPLE Finally Done!”

This is my first in what will become regular contributions to the Tekelec SIP Blog.  In addition to covering SIP from a purely technical perspective, I will look at some of the traction and activities in the market.  This installment focuses on the adoption of IMS, and hence SIP, by mobile operators as the foundation for supporting voice and SMS in LTE environments.

IMS, like many new technologies, has gone through a tremendous “hype cycle”.  There has been the typical name bashing – with claims such as IMS means “I Must Sell” new technologies and the ups and downs of “everyone is moving to IMS” and then “no one is moving to IMS”. While initially developed by the mobile industry in 3GPP, it was widely adopted as a standard by the wireline and cable communities as well.  At this point in time the number of commercial deployments of IMS has been modest by any measure and my guess is that there are probably more commercial wireline deployments of IMS then there are commercial wireless deployments.  However, over the next few years that may all change.

On November 4th 2009, a relatively simple press release was made by a collection of mobile operators on the work that they had collaborated on to create an IMS profile that they named “One Voice”.  Simply put, this profile was created to help the industry secure a common standardized IMS voice (and SMS) solution. To do this, they defined a “profile” or specification that defines a common, recommended feature set from the 3GPP IMS specifications when multiple options exist for a single functionality.  The goal of One Voice was in essence to have a common IMS profile to support Voice and SMS in an LTE environment.

Since then there has been considerable collaboration between the GSMA and participating One Voice companies to enable the profile work to be handed over to the GSMA to take the lead moving forwards. On February 15, 2010, GSMA announced that it had chosen to adopt the One Voice initiative and has given it its full backing.  Having adopted the One Voice profile, the GSMA has opened the work to its entire membership (820+ operators and 220+ vendors) and will work with all interested companies to define protocols needed for LTE voice connectivity.  It will also work to define the interfaces and functional architecture required to enable international roaming and establish interconnection policies between mobile operators, using the One Voice profile as the basis of that work.  This will all result in the definition of end-to-end service principles for Voice over LTE.  The sum total of work will be completed under the name of Voice over LTE, or VoLTE.

This work will hopefully benefit the entire operator and vendor community and move towards broadening the deployment of SIP and IMS-based technologies. The worldwide penetration of mobile phones greatly exceeds that of wireline phones so the adoption of IMS in wireless networks will greatly expand the use of SIP. Of course, the work will take time and LTE will not be deployed over night, although there appears to be growing momentum for LTE in large part driven by the huge uptake in mobile data.

In the mean time, what do I expect to see?  Well, many operators today have deployed VoIP in their core network as part of their R4 soft switch deployments.  However, when the 3GPP R4 specifications were adopted they selected BICC – or Bearer Independent Call Control – as the signaling protocol because of the relative immaturity of SIP at the time.  Over the last 12-18 months we have begun to see some of the R4 soft switches (or MSS) in mobile networks evolve to support SIP in addition to BICC and of course SIP has become the “winner” for next generation signaling.  Recently we have also seen interest in BICC-to-SIP functionality to help mobile operators cost effectively transition to SIP and interwork with other SIP based networks (e.g., international transit networks) from their BICC-based mobile core. 

So will IMS happen in mobile networks as part of the deployment of LTE?  More than likely the answer is yes based on the current direction being pushed by the mobile operators behind the VoLTE initiative. Of course many other questions remain, including: over what time frame will this happen, what is the evolution path, and how long will hybrid 3G-4G networks exist and what challenges will these hybrid networks create for operators?  I will likely address these and other topics in future posts.

Vince Lesch

Tekelec CTO

It may be of interest to readers of this blog that recently a thought-provoking Internet Draft was published by Henry Sinnreich et al: SIP APIs for Communications on the Web – draft-sinnreich-sip-web-apis-00. In a nutshell, the Internet Draft exhibits critique of SIP and suggests a consequent usage of HTTP technology for VoIP used along with other Internet applications.

The question begs, whether the critique is justified and whether the shortcomings mentioned introduce sufficient pain to make one-self busy with abandoning SIP. I think the critique is largely fair; I’m less sure that there is a time window in which the level of pain can cause such a change.

The critique cites several reasons: standards’ complexity, insufficient consideration of NAT traversal and difficulties to link to web apps – to name the most significant ones. The complexity statement can be easily confirmed by looking at the VoIP RFC Watch site maintained by Nils Ohlmeier or by checking the SIP WG RFC dependency graph. And, NAT traversal has proven itself to be a large problem resulting in the formation of new network element type – the session border controller (SBC). Non-voice apps are indeed still letting us wait for them.

The real question to me is whether these difficulties will create enough motivation to change from SIP to Web technology. The window of opportunity seems closed: complexity can be somewhat lowered; like it or not, we have SBCs for NAT traversal; and web-apps can be built with or without SIP.

Still, isn’t the number of these workarounds a good enough reason to give the HTTP legacy a try? I have recently found out that remote sharing of “smart boards” (i.e. whiteboards with direct output to PCs) works over web port 80 via a third party to facilitate NAT and firewall traversal. Most video apps are using HTTP (even though typically one-way), and the number of emails exchanged via HTTP certainty creates a fair traffic share. To me it looks like we’re already giving HTTP a try…

Recently BICC became the protocol of choice for several wireless operators deploying VoIP trunking backbones. For many it is perceived as a temporary workaround solution.

What I’m asking myself is whether such a temporary solution might possibly stay for longer?

In the IP world we have quite a few examples of “temporary solutions” that have featured momentary advantage, real or perceived, and which have stayed with us. I consider NATs (Network Address Translators) the most important example. NATs translate IP addresses in packets from/to the public Internet to a private address range. This allows for the sharing of a scarce public IP address among multiple devices (real problem) and hiding these devices better. The latter is considered a perceived security feature as the same functionality can be implemented in firewalls without the side effect of changing IP packets. The changes to IP packets can cause dysfunctional applications, errors in security protocols and limitations to redundancy schemes. (See RFC3027 for more).

In the IETF standardization body NATs have therefore been considered as architecturally unsound, or even evil architecture. It shall be added that guarding an “architectural spirit” has allowed Internet technology to develop, stay manageable and prevail. In this spirit the “right answer” to the problem of scarce IP addresses has been proposed: IPv6. NATs have been labeled as a “temporary solution”. However, many years later it is as hard to find a user without NATs as it is a user with IPv6. NATs are to stay and the fate of IPv6 is all but clear.

I think a similar scenario is occurring with Session Border Controllers (SBCs). They solve real problems such as NAT difficulties that have bubbled up to the application layer. They solve temporary problems such as interoperability of immature implementations. They also solve perceived problems — we know yet too little about what security problems are out there but SBCs offer an answer already. However, the coincidence of solving real problems and claims they are of a temporary nature seems to me remarkably similar to NATs. I think this may lead to a similar ending, with SBCs staying and solving the problems that are compelling and permanent. Certainly, re-connecting disjoint IP addressing spaces would be one of those.

What is the next controversial architecture to stay? NATs are definitely staying, SBCs keep “temporarily” reconnecting disjoint address spaces. The capability to solve compelling problems has prevailed over desires for a consistent and presumably easier-to-maintain architecture. Recently, several BICC deployments have emerged — is BICC going to be the next protocol that is “architecturally unsound”, yet here to stay?

The BICC architecture is very special-purposed and therefore of limited applicability. Basically, it inherits encoding from ISUP, and transports it over IP or even ATM. Development beyond the purpose of trunking began stalling at “CS3″ (Capability Set 3). By any measure it is a real hybrid vehicle.

Still, as unappealing as it sounds, deployments are reported and continue to solve the MSC trunking scenario. We can soon witness again an architecture solving a real problem and prevailing over “grand architectures” in specific use cases.

It appears that the notion of hybrid vehicles is not exclusively owned by the automotive industry.

Happy New Years!

This is my third, and probably last for a while, post on RFC 4474 and the barriers to deploying strong identity solutions.

RFC 4474 does more than just provide identity. It also provides cryptographic protection of several fields in a SIP request as well as the request body. Each of these data elements are protected for one reason or another. For now, let’s focus on the message body.

In a typical INVITE request the message body contains an SDP payload that describes, among other things, the IP address and port at which the sender wishes to receive media. If that request was signed by an RFC 4474 identity service, the SDP payload is digitally signed. If an attacker tampers with the content in route, the recipient will be unable to verify the signature, and will know something fishy is going on.

Why would you care if someone tampered with your (or your peer’s) SDP? Imagine for a minute that RFC 4474 did not protect the SDP content. Alice sends an INVITE request to Bob, but Mallory performs a MITM attack. Mallory passes the request on with the identity information intact, but changes the IP address in the SDP body. Bob verifies the signature on the identity information, and has good reason to believe the request really came from Alice–but when Bob sends RTP media, he’s talking to Mallory instead.

This scenario could be worse than if no identity service was used at all, as Bob might divulge confidential information that he would not consider saying over an “unprotected” call. Therefore, RFC 4474 requires protection of the request body.

Enter the Session Border Controller, or SBC. One feature that most SBCs have in common is the ability to pin media sessions so that all media packets are sent through the SBC. The SBC sits on the signaling path (as a SIP B2BUA) and modifies SDP offers and answers so that the endpoints send all media packets to the SBC, which then forwards the packets on to their original destination.

There are a number of reasons to do this, many of which are in support of business requirements. (I will avoid the temptation to discuss whether all those requirements are reasonable–suffice it to say that many network operators require them). For example, many operators use SBC-based media pinning to deal with NAT traversal requirements.

But this common SBC technique is exactly the same as the MITM attack technique that Mallory used against Alice and Bob a couple of paragraphs back. The endpoints can’t tell the difference between Mallory’s malicious attack and the SBCs attempt to be helpful. Or to state it more strongly, from the endpoint perspective, the SBC’s modification of SIP message bodies is indistinguishable from an attack.

The world of business requirements is a messy one. It’s common for requirements to conflict with one another, and service providers must make their own priority decisions. But as a customer of such services, I would be willing to pay more to get a strong identity service. I doubt I’m the only one.

Last month, Ravi commented on the voice-centric SIP architectures being deployed by carriers. I’d like to expand a bit on the nature of concrete applications that extend beyond traditional telephone replacement, to give a better idea about what current carrier (and enterprise, for that matter) deployments are precluding.

If you’ve been following SIP, you’re probably aware of the protocol extensions that we’ve standardized in the IETF for Presence, and the (actually unrelated) extensions we’ve developed for Instant Messaging. I’m not going to go into details about these technologies at the moment — they’re powerful, but they’re not especially innovative by themselves. For the most part, we’re standardizing technology that has been available in proprietary forms for 15 years or more.

The real innovation, as is usually the case, comes from the market itself.

One of the things that showed up at the most recent SIPit interoperability test events was an innovative portable real-time camera for remote collaboration. Its intended use is for remote locations, like off-shore oil drilling platforms. A field technician can use the camera to show an off-site engineer what’s happening with equipment in the field. The engineer can then use a whiteboard application to draw on the image (e.g., “Can you zoom in on the part I just circled?”). It also provides two-way voice communications to facilitate the use of its other functions.

And the whole session is managed using SIP — nothing proprietary, just SIP.

I’ve seen a double-handful of other actually-deployed SIP devices that are nothing like POTS replacement (such as remote video monitoring and building-wide intercom systems), but that’s the one that shows off SIP’s potential for innovation better than any others I know about.

There is a tremendous pitfall in the fact that SIP has been picked up as a good protocol to replace traditional telephone service. Because of the huge deployed base of traditional telephone users, the penetration of SIP in this application has been rapid and clearly visible. And SIP is a good protocol for setting up voice calls. However, SIP has huge promise beyond this, and people are developing applications in radically innovative ways that have nothing to do with telephones. Like all technologies, these will take a bit of time to mature — keep in mind that the telephone has a 135-year head start on anything invented today.

Carriers and enterprises that deploy SIP networks as if they’re nothing other than telephone-over-IP completely miss the point. They preclude the future possibility of deploying these kinds of innovative new applications without forklift upgrades of their networks. Ironically, many of these are the same carriers and enterprises that invest in a new SIP network — making it aggressively voice-only through the use of Session Border Controllers (SBCs) and other limiting architectural assumptions — and then ask where all the new applications are. The harsh answer is: you killed them by making them impossible to deploy in your network.

And if you don’t want new applications, then moving to SIP is a pretty extravagant waste of money and time. Because, let’s face it, telephones have done a pretty good job at providing basic voice services for the past 135 years, using technology that has changed very little in the past 30 years.

Talk has become so cheap that we don’t want to talk about cheap talk any more. Well, that was the idea of SIP, to truly move beyond voice, beyond network boundaries of the past and free us from the shackles of that dull, boring Voice. But that does not seem to be the case in the operator networks of today, at least for now. Every SIP conversation that I have had with operators, every real SIP deployment that I have come across in an operator network, I hear voices!!!

Voice-centric SBC’s that are grumbling because they cannot lift the heavy load of voices… unhappy softswitches confined to the voice core, MSC Servers trying to pick between BICC and SIP to carry voice signaling, confused IMS trying to figure out its raison d’être beyond voice…

The reason for SIP was never to replace something that is working fine, but it got trapped somewhere along the way to become voice focused. This is to be expected. Despite the continuing decline in the potential of voice revenue, it is still the cash king for the service provider. Operators (maybe with a few exceptions) will continue to invest in new technology such as SIP in their voice networks for a few more years.

But that is not my concern. In my view, what seems to be not right is that we are building these SIP networks with an architecture that is too voice-centric. The burden of voice may be too heavy to lift when it comes time to go beyond voice.

A few examples:

Deploying border devices that break the end-to-end transparency of a session (read Jiri Kuthan’s blog posting – “Back-to-Back User Agents (B2BUA) Considered Harmful for Service Providers“).

Network implementations that combine the media functions with Session Controllers in a single box. Many of the scalability issues we are seeing with SBC deployments are due to this fact.

Network implementations that combine the SIP UA functions (MSC Servers and Softswitches) and SIP Proxy/Routing functions (SIP Signaling Routers). These two functions not only scale differently, but also have different dependencies from a network evolution perspective. SIP UA have some media dependency (for example an MSC Server deals only with Voice and SMS) where as SIP Routing functions are independent of media and access. 

SIP is just a protocol, but its power comes from some underlying architectural principles that are more important than the bits and bytes of a protocol. Our near term goal may be to solve a Voice problem. But this should not dictate the future network architecture that will be the foundation for multi-media communication services. A few key principles to look for in a SIP network design:

• Avoid breaking end-to-end transparency at the service layer
• Decompose independent functional blocks that scale differently and have differentevolution profiles
• Reuse functional components (Horizontal model of IMS versus Silo model) for multiple media and service compositions

Have you come across problems in the network that resulted primarily because some core architecture principles were compromised? What were those core architecture principles? How could that have been avoided? I would like to hear from your experience.

Technology-savvy observers have witnessed that two concepts for building SIP servers emerged over the past decades — that of a proxy server as specified in RFC3261 and that of a so-called back-to-back user agent (B2BUA).

In this posting I’m building upon a recent discussion in the IETF standardization body, which reconfirmed to me that use of the B2BUAs has a vastly negative impact on service provider’s competition capabilities.

Let’s review those two elements before I proceed to conclusions. The key difference is that a proxy server is a passive element whereas a B2BUA is an active one. The proxy server, inspired in its concepts by IP routers, merely verifies SIP signaling messages and routes them to a proper destination, sometimes partially modifying those. This is the original notion of a SIP server as laid down in the SIP architecture specified in RFC 3261. The architecture has been primarily aiming Internet-grade scalability challenges.

On the contrary, a back-to-back user agent inserts itself actively in SIP calls. It splits a call in two legs and presents itself as callee to the caller and as caller to the callee. This behaviour allows the B2BUA to play a more active role in call processing as it can impersonate both SIP telephones involved in a phone conversation, and implement certain features on their behalf. B2BUAs are frequently located inside so called Session Border Controllers (SBCs).

There have been many educated conversations in the past trying to compare these two concepts to each other. Properties under debate included scalability, transparency, feature richness, level of call control, message integrity, and even more.

Let me however focus on two aspects I consider of utmost importance to service providers: time-to-market and operational expense. These characteristics are of business nature and thus may seem only indirectly related to the technical discussion. However, there are technical properties of B2BUAs that have very direct business impact.

The single greatest disadvantage of B2BUA is broken transparency. The B2BUAs split each call in two “half’s”. Each of the “half’s” is technically speaking a call on its own in that elements of the messages are not guaranteed to be the same. This single design decision makes life very difficult. Obviously troubleshooting becomes difficult if a call is split in pieces that can’t be easily associated with each other. A troubleshooter located in proximity of a caller sees messages which are dramatically different than those a troubleshooter located close to callee gets to see. It is thus rather difficult to correlate both half’s, especially if there are additional errors under failure circumstances.

Since there is no specification for  a B2BUA, automated monitoring equipment can’t reduce effort efficiently and complex troubleshooting is left to highly skilled human experts. I believe the direction of impact on customer care cost is rather obvious.

Transparency broken by B2BUA also impairs innovation. The B2BUA’s active control of signaling requires understanding of SIP features that are to be communicated between call parties. That’s different from proxy servers that transparently relay SIP messages from one party to another. The fundamental shortcoming of B2BUA is that it simply can never anticipate SIP features introduced by end-devices.

These are very valuable source of innovation and allow to increase value of service providers’ offering  without touching critical infrastructure. Such features are then going to fail traversing the B2BUAs.

Now let’s look how such a feature could look like on the example of identity. I’ve been personally concerned by lack of identity in the Internet generally and with SIP in particular. Lack of  verifiable and traceable identity makes email users and analogically SIP users as well too easily vulnerable to malicious communication using spoofed IDs. I also believe that for success of an identity system, it must have a good migration path. In other words, it must be incredibly simple to deploy and use. Here is an idea: could we use a trivial “Is it really you giving me this call” reverse query before we allow an incoming call to ring?

The answer is simple: yes you can if you do NOT use B2BUAs.

To reiterate my point: proxy servers by being passive allow the infrastructure to communicate new signaling features even if they specifically do not understand them.  To implement a reverse call verification, end-devices can simply exchange a query between themselves that refers to the call attempt. Callee’s telephone asks the address claimed in call attempt “are you really calling me”? If both parties support this  feature, callee’s phone can conclude that a call attempt is having genuine caller id. A SIP proxy server just mediates the reverse query like it does for any other SIP message.

In contract to that, a B2BUA will break such new application. Since it is based on an end-device-implemented feature, the B2BUA probably does not understand the reverse queries. Consequently, it is not able to translate the reference to the initial call in the reverse queries and the caller id verification will fail.

Architecturally seen, broken transparency has a huge price tag associated with it. B2BUAs increase operation cost by making troubleshooting complex and by prohibiting applications that can be deployed in an end-to-end manner without costly interaction with the network infrastructure. In conclusion, I recommend against using B2BUAs in service provider deployments that are concerned with customer care cost and capability to rapidly introduce new services.