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 can be redirected to 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 Registrar Redirect Proxy 1 REGISTER I am signing up SIP User Agent 4 REDIRECT He moved, try 2 INVITE Connect me to 6 Media 5 INVITE Initate call to When a call comes in,a pop-up window lets you know who's calling. 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: 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 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: 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

Voice over IP Basics for IT Technicians White Paper Executive summary The IP phone is coming or has arrived on desk near you. The IP phone is not a PC, but does have a number of hardware and software elements

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

Voice over IP (VoIP) Basics for IT Technicians VoIP brings a new environment to the network technician that requires expanded knowledge and tools to deploy and troubleshoot IP phones. This paper provides

Voice over IP Fundamentals Duration: 5 Days Course Code: GK3277 Overview: The aim of this course is for delegates to gain essential data networking and Voice over IP (VoIP) knowledge in a single, week-long

Overview of Voice Over Internet Protocol Purva R. Rajkotia, Samsung Electronics November 4,2004 Overview of Voice Over Internet Protocol Presentation Outline History of VoIP What is VoIP? Components of

The SIP School- 'Mitel Style' Course Objectives This course will take delegates through the basics of SIP into some very technical areas and is suited to people who will be installing and supporting SIP

The SIP School- 'Mitel Style' Course Objectives This course will take delegates through the basics of SIP into some very technical areas and is suited to people who will be installing and supporting SIP

SIP: Protocol Overview NOTICE 2001 RADVISION Ltd. All intellectual property rights in this publication are owned by RADVISION Ltd. and are protected by United States copyright laws, other applicable copyright

VoIP Architecture VoIP: Architectural Differences of SIP and MGCP/NCS Protocols and What It Means in Real World VoIP Service Marcin Godlewski Lead Engineer Scientific Atlanta, a Cisco Company Charles Moreman

An Overview of - Interworking 2001 RADVISION. All intellectual property rights in this publication are owned by RADVision Ltd. and are protected by United States copyright laws, other applicable copyright

This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into

Lesson 1 Abstract Introduction to VoIP Technology 2012. 01. 06. This first lesson of contains the basic knowledge about the terms and processes concerning the Voice over IP technology. The main goal of

Internet Technology Voice over IP Peter Gradwell BT Advert from 1980s Page 2 http://www.youtube.com/v/o0h65_pag04 Welcome to Gradwell Gradwell provides technology for every line on your business card Every

Security and the Mitel Teleworker Solution White Paper July 2007 Copyright Copyright 2007 Mitel Networks Corporation. This document is unpublished and the following notice is affixed to protect Mitel Networks

CHAPTER 4 Call Control Protocols and IPv6 in IP Video Solutions Revised: March 30, 2012, Protocols provide a complete set of specifications and suite of standards for communications between devices, This

MITEL SIP CoE Technical Configuration Notes Configure the Mitel 3300 MCD 4.1 for use with Broadworks Softswitch SIP CoE 08-4940-00035 NOTICE The information contained in this document is believed to be

MITEL SIP CoE Technical Configuration Notes Configure MCD 4.1 for use with SKYPE SIP Trunking SIP CoE 10-4940-00120 NOTICE The information contained in this document is believed to be accurate in all respects

Title Six Steps To Getting Your Network Ready For Voice Over IP Date January 2005 Overview This provides enterprise network managers with a six step methodology, including predeployment testing and network

MITEL SIP CoE Technical Configuration Notes Configure MCD 6.X for use with babytel SIP trunks SIP CoE 13-4940-00266 NOTICE The information contained in this document is believed to be accurate in all respects

Mobile Voice Off-Load An AdvOSS Solution White Paper Latest version of this white paper can always be found at: http://advoss.com/resources/whitepapers/mobile-voice-offload.pdf For more information, contact

MITEL SIPCoE Technical Configuration Notes Configure Inn-Phone SIP Phone for use with MCD SIP CoE NOTICE The information contained in this document is believed to be accurate in all respects but is not

MITEL SIP CoE Technical Configuration Note Configure MCD for use with SIP Trunking Service SIP CoE NOTICE The information contained in this document is believed to be accurate in all respects but is not

Introduction SIP is fast becoming the Voice over IP protocol of choice. During this 3-day course delegates will examine SIP technology and architecture and learn how a functioning VoIP service can be established.

OfficeMaster Gate (Virtual) Enterprise Session Border Controller for Microsoft Lync Server Quick Start Guide October 2013 Copyright and Legal Notice. All rights reserved. No part of this document may be

Gateways and Their Roles Understanding Gateways This topic describes the role of voice gateways and their application when connecting VoIP to traditional PSTN and telephony equipment. Analog vs. Digital

Fax over IP Contents Introduction Why Fax over IP? How Real-time Fax over IP works Implementation with MessagePlus/Open Summary About this document This document describes how Fax over IP works in general

SJ Labs, Inc. 2005 All rights reserved SJphone is a registered trademark. No part of this document may be copied, altered, or transferred to, any other media without written, explicit consent from SJ Labs

Multimedia Service Platform Turnkey solution for SIP based communications Adrian Georgescu AG Projects http://ag-projects.com Current telecommunications landscape From the old PSTN only the E.164 numbering

The Promise of Convergence, Delivered Communication is essential to business, but it is ultimately conducted at a personal level at the desktop and across the enterprise. So if you re considering a new

Service Guide Learn More: Call us at 877.634.2728. www.megapath.com What is MegaPath SIP Trunking? SIP Trunking enables your business to reduce costs and simplify IT management by combining voice and Internet

ACD: Average Call Duration is the average duration of the calls routed bya a VoIP provider. It is a quality parameter given by the VoIP providers. API: An application programming interface (API) is a source