Technology Primer. SIP Technical Overview. The protocol of choice

Transcription

1 Technology Primer SIP Technical Overview The protocol of choice From its initial standardization in 1999 by the IETF, Session Initiation Protocol (SIP) has rapidly become the protocol of choice for the deployment of IP Telephony as evidenced by the public service offering and announcements from MCI, Vonage, Packet 8, Telstra, SingTel, etc. SIP was also adopted by the Multiservice Switching Forum (MSF) for VoIP and VoATM trunking (SIP & SIP-T). In addition, SIP received a strong boost in 2000 with its adoption for 3GPP networks (third generation mobile). Even today SIP is used to offer such features as PTT (Push to Talk) functionality and basic presence over 2.5G networks (1xRTT and GPRS). This primer is intended to explain some of the concepts underlying SIP, its main characteristics that make it a powerful protocol and the challenges faced by SIP especially in enterprise networks. This primer is intended to complement the first Mitel SIP Primer by providing additional information on the protocol and its capabilities. Both documents are complementary and can be downloaded from the Mitel web site. What is SIP? SIP is a signaling protocol for controlling multi-media sessions. It is used to establish user presence, locate users (SIP enables mobility), as well as set up, modify and tear down sessions. Interaction with other protocols From the previous definition, SIP is not a media or a management protocol. In other words, SIP does not define new codecs, QoS nor is SIP voice specific. SIP relies on other protocols such as RTP to transport user information (audio, video), DNS for address resolution, Diffserv / RSVP etc., for QoS, Radius / Diameter for AAA (Authentication, Authorization, Accounting), etc. SIP does not describe the audio and media components of a session; instead, it relies on a separate session description (SDP) carried in the body of SIP messages (INVITE and ACK). The diagram on the next page shows the interaction of these protocols. Of interest is the fact that SIP can be implemented over UDP or TCP transport. SIP incorporates mechanisms to cover for packet loss with retransmissions based on timers.

2 Similarity to web protocols SIP is modeled after HTTP in that it borrows the concepts of URI, Schemes and Methods as implemented for the HTTP protocol. The Scheme used to identify the type of resource is either SIP or SIPS (Secure SIP) and there are several access Methods (listed in the sections below). This design aspect is a major strength of SIP in that it can readily integrate with other web infrastructures. High level description To better understand SIP, it is appropriate to describe the different components of a SIP solution (SIP messages, SIP elements, SIP message flow). The fundamental tenets of this protocol will be highlighted along with a comparison to existing protocols (e.g., MGCP, H.323). 1. SIP elements At a high level there are two types of SIP elements: User Agents and Servers. User Agents are endpoints in a SIP network: they originate and terminate calls. Examples of User Agents (UA) include: SIP phones (hard sets), laptops or PDA with a SIP client (e.g., softphone), Media gateway (e.g. T1/E1 gateway), access gateway (e.g., FAX gateway), conferencing systems, etc. All these devices also initiate and terminate the media session (voice, video, FAX, etc.). A UA is itself comprised of two entities (software): UAC (initiates call by sending INVITE with E.164 or URI dialing) UAS (receives call requests). More on SIP messages and addressing to follow. There are several types of servers in a SIP network including Proxy server, Redirect server and SIP registrar. A Proxy server performs signaling and relay. In other words, it determines where to send signaling messages and forward requests on behalf of the UA. To do so, it consults databases (DNS, location servers, etc.). It is important to remember that Proxy servers have no media capabilities; they are in the control path only. Proxy servers must pass unrecognized SIP messages Interaction with other protocols Signaling Media Transport QoS Services/Utility Applications SDP Media Coding SIP RTP RTCP DNS DHCP AAA Transport TCP SCTP UDP Network IPv4, IPv6 Link Layer & Physical Layer AAL5 ATM Ethernet WiFi, WiMax PPP V.90, V.34 PPP SONET/SDH 2 Mitel Technology Primer

3 Enter a Name or Phone Number... Lastname, First ( ) Line 1001 Line People People to Call Friends (3 of 16 are online) Missed Calls Henderson, Frank ( ) 2x Today 4:01p Unknown ( ) Today 3:11p Lee, Bill (2342) Today 2:08p Jones, Ralph (5411) 2x Today 1:37p Wilson, Pamela (2454) Today 12:59p 11 New Items In the Office Iím in a meeting File Edit View Favorites Tools Help Enter a Name or Phone Number... Lastname, First ( ) Line 1001 Line 1002 Quick List People to Call Friends (3 of 16 are online) Project Team (1 of 4 online) Brown, Bill (Available) Davidson, Karen (Busy) Call 79 People MITEL through unchanged. Thus new features do not require changes to proxy servers used in an infrastructure. This principle enables new features to be deployed in a network by only upgrading the end devices. The routing function can be configured (programmed) according to user preferences, type of call (e.g., 911), least-gw-cost, or other criteria. Note that the proxy server is not the only place where service can be programmed. In fact, service programmability can reside in end-devices as well, such as for visual caller ID, distinctive ringing or possible Call Forwarding. Proxy servers can try several destinations sequentially or in parallel, this capability called forking enables multiple devices to be associated with the same address. There are three types of Proxy servers according to the type of state information they keep: 1) a stateless proxy keeps no state, 2) a transaction stateful proxy only keeps state on pending transactions, while, 3) a call stateful proxy keeps state for the entire duration of a SIP session. Most implementations are stateful proxy-based as this is useful for implementing such services as forward on no reply and also to implement forking. Stateless proxies are easier to scale (especially under heavy load scenarios) and can act as an application-layer load distributor (used in the core of a network). Redundancy designs are easier to achieve with stateless proxies. A SIP registrar accepts registration requests from users (e.g., I am now at ) and maintains user location information in a database. Mobility is thus achieved by the use of a REGISTER message (from UA) and by keeping a location database updated. Redirect servers are servers that redirect SIP requests to another device. A redirect server responds to the request with the address to which the request should be redirected to (e.g., a request for nic@mitel.com can be redirected to nic@home.com). SIP does not specify any implementation models for example, all above servers can reside on the same hardware platform. The underlying OS can be Windows, Solaris, Linux or any embedded real time OS (QNX, VxWorks, MontaVista Linux, etc.). For example, VOCAL is an open-source VoIP software from Vovida.org. VOCAL software suite is a robust implementation of the SIP protocol and its various entities and is used widely. It is important to note that the above servers (proxy, redirect and registrar) are all optional SIP components. In fact, a UA may issue an INVITE directly to a targeted endpoint and many telephony features may be implemented directly on the UA. The SIP model is based on intelligent endpoints that can act without other intelligence from the network infrastructure (refer to section below on peer-to-peer vs. centralized model). Example of User Mobility Using Register and Redirect Messages SIP Servers 3 Where is nic@mitel.com? Registrar Redirect Proxy 1 REGISTER I am signing up SIP User Agent 4 REDIRECT He moved, try 2 INVITE Connect me to Nic@mitel.com bernard@mitel.com 6 Media 5 INVITE Initate call to nic@home When a call comes in,a pop-up window lets you know who's calling. nic@home.com Mitel Technology Primer 3

4 2. SIP messages There are two types of SIP messages: SIP requests (also called METHODs the same way as GET, PUT, DELETE, POST are METHODs for HTTP) and SIP RESPONSEs (shown in the tables below). SIP requests (as defined in RFC3261) include the following core METHODS: INVITE to initiate a session Re-INVITE if, during a call, either party wants to change the media; for example to open a video channel ACK to confirm session establishment and can only be used with INVITE BYE terminates sessions CANCEL to cancel a pending INVITE OPTIONS for capability inquiry REGISTER to bind a permanent address to current location Other SIP method extensions are defined in different RFCs such as: SUBSCRIBE to subscribe to a service state change. Used for presence (subscribe to an event and receive notification), call-back (when other party becomes available), voice mail notification, any event that can be associated with a trigger (e.g., stock quotes, etc.) NOTIFY notify a change of service state (e.g., new voice message). Works in parallel with SUBSCRIBE MESSAGE for Instant Messaging (user to user messaging). MESSAGE requests carry the content in the form of MIME body parts REFER call transfer PUBLISH publication of presence information to a server SIP is designed so that UAs can discover and negotiate their capabilities including what Methods are supported. Another aspect of negotiating capabilities include codec support, handled by the SDP protocol. One UA in the session generates an SDP message that includes (among other information) all codecs the offerer wishes to use. The answer will indicate whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the recipient wants to use to receive media. SIP responses use a numerical code (borrowed from HTTP response code, e.g., 404 Not Found) and a reason phrase (see table below). Code Type Description 1XX Information Request received continuing to process the request. Example: 100 trying, 180 ringing 2XX Success The action was successfully received, understood and accepted Example: 200 OK 3XX Redirection Further action must be taken to complete the request Example: 301 Moved Permanently, 302 Moved Temporaily 4XX Client error Request contains bad syntax Example: 400 Bad Request, 401 Unauthorized 5XX Server error Request cannot be fulfilled at this server Example: 500 server Internal Error 6XX Global failure Request is invalid at any server Example: 600 Busy Everwhere 4 Mitel Technology Primer

5 3. SIP addressing Because it is IP based, SIP provides users with globally reachable addresses. These addresses (URI) use the same format as an address: (e.g., or Users can have any number of SIP URIs with different providers that all reach the same device. Instead of SIP URIs, users can be identified also by telephone numbers, expressed as tel URIs such as tel: Calls with these numbers are then either routed to an Internet telephony gateway or translated back into SIP URIs via the ENUM mechanism. ENUM description The fundamental problem ENUM tries to solve is the mapping between a standard telephone number and a SIP URI. In enterprise networks today, this problem is addressed using vendor proprietary implementations. These include routing tables (in gateways, proxies, etc.) to translate the dial strings to a host name to set up a call. ENUM is a better solution (especially for public VoIP service) because it solves inter-domain call routing based on a telephone number. In fact, until ENUM, there had been no practical solution to the problem of call setup across these domain boundaries. The ENUM solution consists of a DNS-based architecture and protocol to map dialed numbers to SIP URIs. In addition to providing the SIP URI, ENUM can also provide such information as address, cell phone, VPIM information and FAX number. The advantage of using DNS is that it can be delegated and it is scalable. In fact, each digit can be a definable DNS zone and zones can be delegated. From a user s perspective, ENUM is a transparent process. The ENUM logic and DNS resolution are carried out in the background by ENUM-enabled devices, proxy servers or gateways. After a user dials a phone number (e.g., ) the number is translated into a Fully Qualified Domain Name (FQDN) that can be used by the DNS. For example, the above number can be translated into e164.arpa. This FQDN is queried for NAPTR Resource Records. These records define the services that can be associated with a particular telephone number in ENUM, including SIP VoIP, fax, , instant messaging, personal web pages, etc. In this case, the SIP phone or proxy would parse the NAPTR records looking for the service field that contained SIP. It would ignore all other records ( mail to, tel, etc.) and then issue a SIP INVITE message to: sip:nic.dufeu@publicsip.net in order to connect the call. The example depicted below shows how ENUM can operate between two SIP phones. The ENUM resolution service is invoked from a SIP phone that issues a DNS query after the user dials a phone number (e.g., ). The information obtained from the NAPTR records is used to establish the call. In the case of an analog phone, the ENUM service can be implemented in the media gateway. ENUM Description DSN Server 1 Query e164.arpa 2 Response SIP:nic.dufeu@ publicsip.net 3 INVITE INVITE User dials Mitel Technology Primer 5

6 4. Examples of SIP message flow An example of a SIP message flow is shown at the right. To make a phone call for example, a SIP UA sends an INVITE request. In the message body, the UA specifies the type of media available. The outbound (receiving) Proxy server routes the request across the network until it reaches its destination (multiple proxies can be involved). DNS Server Outbound 1 INVITE Contact:A SDP A Trying 3 INVITE Contact: A SDP A Trying 5 LS Query: B Location Server 6 Response: sip:b@ Inbound 7 INVITE Contact: A SDP A User Agent A User Agent B When the called party receives the INVITE request, it determines if it can accept the call in which case, it will ring the phone and sends a provisional response back to the caller (to indicate that the phone is ringing). Outbound Ringing Inbound Ringing Ringing User Agent A User Agent B When the phone is answered, the called UA sends a final response with the media channels that it can support. Both parties agree on a media channel and the caller UA sends an ACK to the called UA. RTP streams can flow between devices. Outbound OK Contact: B SDP B Inbound OK Contact: B SDP B OK Contact: B SDP B 14 ACK User Agent A User Agent B Media (RTP) Diagrams above borrowed with modifications from Henry Sinnreich & Alan Johnston. 6 Mitel Technology Primer

7 5. SIP and other protocols An important difference between SIP and other protocols is the fact that SIP endpoints can communicate directly. In other words, two SIP sets do not require any resources to establish a peer-to-peer communication, much in the same way that two PCs can exchange a file (e.g., FTP client / server) without any other devices. This capability is in contrast with stimulus based VoIP protocols such as MGCP that require intelligence to be located in the network (Media Gateway Controller) for device control. Stimulus based protocols (e.g., MGCP, Megaco / H.248, PacketCable / NCS) have been deployed in large scale public networks for hosted IP Telephony (e.g., GoBeam / Covad, Tiscali, Equant, etc.). The majority of enterprise networks deploying VoIP today also use some type of proprietary stimulus based protocol. SIP is also superior to H.323 in many respects. First, it is flexible in that it can be implemented over TCP, UDP or SCTP and is not restricted to telephony only applications. Second, H.323 protocol structure is inherently much more complex, hence more difficult to implement. Third, SIP is inherently more extensible due to its HTTP-like method / tags / MIME approach. SIP message structure (textual encoding) makes it easier to implement and add new functionality than H.323 that uses the ITU s ASN.1 encoding standard instead of text. Lastly, SIP servers can be stateless (thus easier to scale) and SIP servers can ignore unknown headers whereas compatibility is required to operate; for example an H.323v3 end-device on an existing H.323 infrastructure. MGCP and SIP can co-exist in VoIP networks, they can especially be complementary in an environment with multiple softswitches (CA / MGC). This scenario depicted below consists of using MGCP to control trunk gateways, low-end VoIP sets and IAD to deliver CLASS features / services (but not advanced capabilities such as presence, or video). SIP (or SIP-T) is then used between Call Agent / MGC. SIP and other protocols SoftSwitch SoftSwitch SIP MGCP MGCP RTP Gateway Gateway Mitel Technology Primer 7

8 6. Protocol highlights and summary In summary, some of the fundamental tenets of the SIP protocol are: IP based protocol uses IP addressing End-to-end protocol messages make it to the other end unaltered Unbundling of network transport from services ASP can augment service offering Unbundling of services and applications quickly add new applications No service intelligence in the network network has routing knowledge and forwarding capabilities No state knowledge or service logic in the network further unbundling between network and service Call and state intelligence resides in end devices easy to scale total solution Intelligent endpoints can communicate without any other resources Client server based protocol Textual encoding easy to implement and troubleshoot Multimedia can be used for voice, video, gaming, IM, etc. While some of the above points also characterize the PSTN and its underlying protocols (e.g., SS7), SIP enables a new level of autonomy between services and applications, furthermore, services may be offered by different providers (ASP). In other words, a user can subscribe to more than one provider for signaling (a side benefit is to gain back service in case of failure) to another provider for connectivity to legacy networks, while subscribing to an ASP for an IVR service, for example. Most importantly, adding a new application or functionality is a trivial exercise when compared to adding the same functionality to a legacy PSTN network. SIP Enables a new Business Model Between Service Providers Services Business Entity Applications AS ASP VoIP Infrastructure PS/CA MG MS VoIP SP Packet Infrastructure Routing Routing Transmission NSP Legend: AS: Applications Server PS: CA: Call Agent (MGCP model) MG: Media Gateway (e.g., Nuera) MS: Media Server e.g., Convedia) 8 Mitel Technology Primer

9 File Edit View Favorites Tools Help Enter a Name or Phone Number... Lastname, First ( ) Line 1001 Line 1002 People to Call Friends (3 of 16 are online) Project Team (1 of 4 online) Brown, Bill (Available) Davidson, Karen (Busy) Call 79 People 11 New Items Henderson, Frank ( ) 2x Today 4:01p Unknown ( ) Today 3:11p Lee, Bill (2342) Today 2:08p Jones, Ralph (5411) 2x Today 1:37p Wilson, Pamela (2454) Today 12:59p Auto Answer In the Office Call Forward Profile Iím in a meeting Context sensitive instructional text displayed here... File Edit View Favorites Tools Help Enter a Name or Phone Number... Lastname, First ( ) Line 1001 Line 1002 Quick List People to Call Friends (3 of 16 are online) Project Team (1 of 4 online) Brown, Bill (Available) Davidson, Karen (Busy) Call 79 People MITEL 7. SIP and third-party control SIP is designed so that two entities (users / services) can jointly establish a communication. Some services however require a third party involved to establish the communication channel. This is the case for example of click-to-dial (where a controller establishes a call on the caller s behalf), IVR (where the AS determines where to send the call after initial input from the caller) or prepaid calling (where the caller initially enters information into a controller). Third-party Control refers to the ability for a device that is not one of the ends of the SIP signaling to affect a SIP dialog. Third-party Call Control is not a SIP extension but a clever mechanism that allows a controller (UA) to independently exchange signaling with two parties (A & B) and convinces them to send media to each other. In fact, the two parties believe that they are in session with the controller but effectively they are sending media to each other. SIP and third-party control 8. Presence, IM and SIP SIP enables basic messaging between two parties (using the SIP MESSAGE method described above. The MESSAGE method provides pager-mode messaging where messages sent are independent of each other (no concept of a session) similar to a two-way pager service. The request may traverse a set of SIP proxies, using a variety of transports, before reaching its destination. This mode, suitable for short messages or broadcast information (e.g., server re-boot in two minutes), has been criticized for its relative high overhead and lack of true IM functions. An IETF working group (SIMPLE or SIP for Instant Messaging and Presence Leveraging Extensions) is focused on the application of the Session Initiation Protocol to Instant Messaging and Presence (IMP). One of the main benefits of this effort is the recognition of the distinction between presence and messaging and to standardize the protocol to enable interoperability with different vendors. A second mode (session-mode) was introduced to provide ordering security. This mode was designed not to burden the SIP signaling network by working directly between the endpoints. There is, however, more complexity (e.g., a new protocol: MSRP must be implemented in end devices) to contend with. It is important to note that the IETF has also blessed other competing specifications for Presence and Instant Messaging, notably XMPP (jabber). Presence, IM and SIP SIP MESSAGE method is used to send instant messages, where each message is independent of any other messsage Application / Feature Server Third-party control, also called centralized model because it requires a central point of control, may not be desirable in some environments. An alternative approach to perform call control is based on a peer-to-peer model (distributed) which uses SIP REFER and Replaces Header. The Replaces Header is used to logically replace an existing SIP dialog with a new SIP dialog. One use of the Replaces Header is to replace one participant with another and is frequently used in combination with the REFER method, for example to retrieve a parked call. Message 200 OK Mitel Technology Primer 9

10 9. SIP-based deployment This section provides three examples of SIP deployment: one in public networks, one in enterprise networks and one in private-public applications. 1. Augmenting existing Class 5 switches with SIP Traditional service providers while wanting to offer new services leveraging the power of SIP also place a great emphasis on preserving their investment in TDM infrastructure. A SIP-based solution should co-exist with the existing Class 5 switches while allowing service providers to generate a new stream of revenues from existing and new subscribers. This is the premise behind products such as the Mitel 3600 Integrated Communications Platform (ICP) server (or product offering from other vendors) that as a SIP Small Business Feature Server, it can connect to legacy switches and deliver a whole range of advanced IP services. Some of these services include web portal, mobility, teleworking and self-provisioning. Augmenting Existing Class 5 Networks with SIP Class 5 switch PSTN PRI Broadband Network Mitel 3600 ICP Server Gateway 10 Mitel Technology Primer

11 SIP-Based Unified Messaging Deployment Site #2 Traditional Centrex Service Traditional PBX digital IP/ VPIM PSTN NuPoint UM - SIP IP WAN Site #3 T1 SMDI IP/ VPIM NuPoint UM - SIP IP / VPIM Site #1 NuPoint UM - SIP Layer 2 SIP IPBX 2. Migrating to next generation SIP-based messaging systems Many enterprises are faced with the upgrade of their VMS that reach their end of life cycle and look to enable new functionality such as unified messaging. Selecting a SIP-based platform is a difficult choice. In fact, the platform has to integrate with the legacy PBX and legacy VMS (in the case of distributed networks). This implies that the SIP-based Media Server must accommodate analog or digital connectivity to PBXs (in addition to IP) and support message exchange using VPIM and AMIS. This capability exists today on the Mitel NuPoint Messenger Model 70 IP (offerings from other vendors too). The Mitel solution supports native SIP in addition to the integration to a dozen traditional PBXs. Using a flexible SIP media server, such as the NuPoint Messenger Model 70 IP, enterprises can smoothly migrate to a SIP infrastructure and accommodate distributed as well as centralized messaging architectures as depicted above. Mitel Technology Primer 11

12 3. Merging IPBX with public VoIP infrastructures using SIP Customers using a hosted or Centrex service, have traditionally had limited access to advanced applications such as teleworking, unified messaging, contact center applications, conferencing and collaboration solutions. On the other hand, customers deploying IPBX face many challenges in deploying multi-site networking including: (1) site-to-site connectivity over IP, (2) managing PSTN connectivity, (3) managing billing (one bill for all sites), (3) configuring dialing plans, (4) call routing, etc. IPC 2 is the SIP answer from Marconi and Mitel (offering available from other vendors) to enable service providers to leverage IPBX for advanced features at the customer premises while offering business trunking and VPN services using a soft-switch architecture (other services are also enabled in this architecture). Business trunking and VPN services enable customers to control their IPBX while billing, call routing and site to site connectivity are handled by the Service Provider. Merging IPBX with Public VoIP Infrastructures Using SIP Head Office Regional Office PSTN Legacy PBX Mitel 3300 ICP Mitel 3300 ICP Network Gateway Voic Application Server Media Firewall IP-VPN SoftSwitch Other Application Branch Office Remote Users Video 12 Mitel Technology Primer

13 10. Centralized vs. distributed deployment models B2BUA One of the fundamental premises behind SIP is its distributed nature and the fact that calls are end-to-end. SIP servers as noted throughout are optional. Several vendors, deviating from the previous model, offer a centralized architecture also referred to as back-toback User Agent implementation (B2BUA). Such architecture consists of using the SIP server as a mediation device for all calls. In other words, a B2BUA server appears just as another SIP endpoint and can modify the message (as depicted below). SIP-based B2BUA Deployment Model Dialog #1: UAS Dialog initiated 1 User Agent 1 SIP Server: B2BUA Implementation 4 2 With a B2BUA implementation, it can be easier to offer PBX-like features, manage calls end-to-end (CDR, billing, etc.), implement and enforce policies (CoS, CoR, etc.) and address NAT issues (described in the next section). A market segment where this solution is well received is Small and Medium size businesses (<5,000 users) where customers prefer a central point of service for all users and where policies, security, firewall and other services can be managed, enforced and terminated. 3 User Agent 2 Dialog #2: UAC Dialog initiated 11. SIP and management Managing traditional telephony relies on proprietary vendor implementations to address such issues as fault management, configuration management (adding a user), accounting (extracting CDRs), performance and security (setting a COR or policy). By disagregating the PBX (and the Class 5 switch), IPT (SIP included) enables the deployment of a standards based management framework. This framework includes protocols such as Radius for AAA (user policy configuration, accounting, etc.), LDAP for Directory, SNMP MIB for user and network devices, SNMP traps to collect alarms from multiple devices and FTP / TFTP servers to collect and retrieve metrics (RTCP, etc.). Furthermore, web tools (web browsers) can be used to view and configure the above information, lastly more sophisticated system / network managers (HP OV NNM) can be used to manage all above network elements (IP sets, trunk gateway, etc.). While in theory, IPT can re-use the existing data management framework, it is a challenging task for many enterprise network managers to integrate disparate network elements (media gateways, user agents, media servers, etc.) into their existing management infrastructure. Service providers, on the other hand, are faced with many new challenges such as Service Level Management (integration with multiple network elements), user self-configuration (security issues) and unifying information from different devices (many devices generate CDRs). 12. CALEA and E911 / E112 Delivering E911 service in SIP-based networks add a layer of complexity that is best understood when trying to address some of the questions below: Users can move to a different house without calling the carrier. Who is responsible for routing their calls to the appropriate PSAP? E.164 numbers may not reflect geographic area as a caller in California may have a NY number If the Proxy server must determine where to route the emergency call then where does it route the call if the user is in a different state? Mitel Technology Primer 13

14 If the call is disconnected can the PSAP contact the initiator of the emergency call? Where to? Who provides this information? Who provides Caller Identity Validation? If there is no intelligence in the network, there may be no VoIP SP involved and ISPs do not track what type of packets are sent. How will the user contact the appropriate PSAP? In the above scenario is the ISP responsible to guarantee call completion? In the long-term, users may not have E.164 numbers What URI is used? Is it ubiquitous? How to determine location information? Who maintains location information? Will it handle mobility? Other issues, not SIP related, include: Mobile and traditional analog phones do not have a power supply whereas most SIP desk phone will stop operating under power loss Who should pinpoint the exact location of user in a WiFi hotzone (and how)? How is this information conveyed to the user? To the PSAP? There are several technologies available that can come to the rescue (e.g., DHCP tagging and extensions to identify location, triangulation, GPS, etc.). In general, there is an agreement that a SIP-based VoIP offering should proceed ahead as these issues are being addressed in various organizations (NENA, APCO, CGALIES, ETSI, etc.). To support CALEA (Communications Assistance for Law Enforcement), a telecommunications carrier must ensure that its equipment, facilities, or services are capable of isolating and enabling the government to intercept all wire and electronic communications and providing access to call-identifying information. Using a pure SIP packet-based infrastructure however introduces new challenges in that there is no standard handover interface for packet-based networks into an LEA collection node (Law Enforcement Agency). Furthermore subscribers may not be identified using a fixed directory number but using SIP URL. 13. Other SIP challenges SIP has been proven in deployments exceeding 200,000 users (Free World Dialup, Vonage, SIP.edu initiative, etc.). Complex issues remain including reliability, feature richness, security, privacy and NAT traversal. Reliability issues are mostly evident in implementations of stateful proxies during failure of the primary proxy server. Failure detection and switchover can take a long time especially if SIP over UDP is implemented (rather than TCP). Lack of feature support is not a SIP limitation, it is rather a result of a vendor s decision to offer a limited number of features, but interoperable. There is ongoing effort the support of a large number of features in SIP (SIMPLE). Securing a protocol like SIP is very complex. Issues include authentication, authorization, message integrity and privacy. These security issues are being addressed by extensions to the protocol. SIPS, similar to HTTPS, mandates the use of a secure transport protocol, such as TLS, between trusted entities. S/MIME (RFC 1847) is for end-to-end message authentication and validation, and encryption of message bodies. These extensions are not widely implemented yet. NAT traversal is a relatively complex issue. The challenge is getting media sessions to pass through NAT devices when the caller is trying to reach a party behind a NAT device. Several solutions have been proposed such as STUN and TURN. These solutions have their own drawbacks. In the case of STUN it does not work across all types of NAT devices (more specifically symmetric NAT). Another approach is the use of Application Level Gateways (ALG) that are specialized firewalls that understand specific IP protocols such as SIP, and dynamically open those ports needed by the application leaving all others securely closed. Upgrading a firewall with ALG functionality can be expensive, as the firewall needs to have intimate knowledge of protocol implementations. This would also imply that amending a protocol or adding new protocols requires infrastructure change. So much for unbundling infrastructure from applications. 14 Mitel Technology Primer

15 In conclusion SIP deployment in the enterprise The main appeal of IPT is to enable new applications including convergence to the user and to lower the total costs of operating a voice network. The main appeal of SIP is in its standards based approach that ultimately offers customers even better ROI (Return on Investment) by offering a wider selection of appliances, servers, services, etc., (side benefit of competition). The ROI is also achieved by not locking customers into a proprietary protocol that will prove expensive to migrate from. To some extent, the success of SIP in public networks contrasts with a milder reception of SIP into enterprise markets where vendor protocols (Cisco / SCCP, Mitel / Minet, Nortel / UniStim, Avaya / CCMS+H323, etc.) are mostly being deployed. It is important to note that a basic level of interoperability can be easily achieved between different vendors (Mitel, Cisco, Polycom, Broadsoft SIP proxy server, etc.). In fact, Mitel SIP phones can be added to a SIP infrastructure with Cisco SIP sets alongside with other sets from Polycom. More advanced features however (IM, security, etc.) or private SIP extensions are not always supported across all vendors and some integration work is required for more complex settings (e.g., contact centers, unified messaging and notification, VPIM to legacy VMS, etc.). For more on SIP, go to: SIP WG Supplemental Homepage The SIP Center www1.cs.columbia.edu/~xiaotaow/sipc/ UoColumbia SIP User Agent (sipc) Ubiquity SIP user agent For more information or to evaluate Mitel SIP solutions, please contact your local Mitel Sales and Systems Engineer or visit our web site at While integration is not an issue for service providers or large enterprises, it can represent a substantial effort for medium size organizations (<5,000 users). This could be one of many reasons why SIP is lagging in medium size enterprise networks. As SIP matures and more interoperability testing is conducted, SIP will become the dominant protocol in enterprise markets. Mitel Technology Primer 15

16 Acronyms 1xRTT Single Carrier Radio Transmission Technology 3G Third Generation (wireless) 3GPP 3G Partnership Project (UMTS) AAA Authentication, Authorization and Accounting (IETF) AG Access Gateway APCO Association of Public-Safety Communications Officials AS Application Server ASP Application Server Provider CDR Call Detail Recording CGALIES Group on Access to Location Information by Emergency Svs CLASS Custom Local Area Subscriber Services, aka Custom Calling features COR Class of Restriction COS Class of Service DTMF Dual Tone/Multiple Frequency ENUM E.164 Numbering in DNS (IETF RFC 2916) ETSI European Telecommunications Standards Institute FQDN Fully Qualified Domain Name GK Gatekeeper GPRS General Packet Radio Service IETF Internet Engineering Task Force IMP Instant Messaging and Presence ISP Internet Service Provider IVR Interactive Voice Response JAIN Java Application Interface Network LDAP Lightweight Directory Access Protocol (IETF) MG Media Gateway MGCP Media Gateway Control Protocol (IETF, ITU-T J.162) MPLS Multi-Protocol Label Switching MS Media Server MSRP Message Session Relay Protocol NAPTR Naming Authority Pointer NCS Network Call/Control Signaling (PacketCable MGCP) NENA National Emergency Number Association NGN Next Generation Network PA Presence Agent PUA Presence User Agent PBX Private Branch exchange POTS Plain Old Telephone Service PSTN Public Switched Telephone Network QoS Quality of Service RFC Request For Comment (IETF) 16 Mitel Technology Primer

17 ROI Return on Investment RTCP Real Time Transport Control Protocol (IETF) RTP Real Time Transport Protocol (IETF RFC 1889) SCTP Stream Control Transmission Protocol SDP Session Description Protocol (IETF RFC 2327) SIMPLE SIP Instant Messaging and Presence Leveraging Extensions SIP Session Initiation Protocol (IETF) SIP-T SIP For Telephony (IETF) SNMP Simple network management protocol SP Service Provider SRV Server location records extension to DNS TDM Time Division Multiplexing TRIP Telephony Routing over IP (IETF RFC 2871) UA User Agent URI Uniform Resource Indicator VoIP Voice over IP VPIM Voice Profile for Internet Mail XMPP Extensible Messaging and Presence Protocol Acknowledgements The author would like to thank the many colleagues throughout industry and academia in the IETF SIP, SIMPLE and SIPPING working groups that develop IP communications technology. The information in this document is believed to be accurate at the time of publication. Contact Mitel directly for updated information or for more details. North America (613) Latin America (613) UK Tel: +44 (0) Fax: +44 (0) France Tel: +33 (0) Fax: +33 (0) Benelux Tel: +31 (0) Fax: +31 (0) Italy Tel: Fax: Germany, Switzerland, Austria Tel: +49 (0) Fax: +49 (0) Portugal and Spain Tel: Fax: Middle East Tel: Fax: South Africa Tel: Fax: Asia-Pacific Tel: Fax: THIS DOCUMENT IS PROVIDED TO YOU FOR INFORMATIONAL PURPOSES ONLY. The information furnished in this document, believed by Mitel to be accurate as of the date of its publication, is subject to change without notice. Mitel assumes no responsibility for any errors or omissions in this document and shall have no obligation to you as a result of having made this document available to you or based upon the information it contains. M MITEL (design) is a registered trademark of Mitel Networks Corporation. All other products and services are the registered trademarks of their respective holders. Copyright 2004, Mitel Networks Corporation. All Rights Reserved. GD 7815 PN RA-EN