MItel Technology Primer

MITEL
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). 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.
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.
MITEL
Technology Primer | SIP
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.
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
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).
Interaction with other protocols

Signaling Media Transport QoS Services/Utility
SDP Applications SIP
Media Coding
RTP
RTCP
DNS
DHCP
AAA
Transport Network
TCP
SCTP
UDP
IPv4, IPv6
AAL5 Link Layer & Physical Layer ATM Ethernet WiFi, WiMax
PPP
PPP
V.90, V.34
SONET/SDH
| Mitel Technology Primer
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 192.168.0.10) 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

3 Where is nic@mitel.com?
SIP Servers
Registrar
Redirect
Proxy
1 REGISTER I am signing up
4 REDIRECT He moved, try him @home.com 2 INVITE Connect me to Nic@mitel.com
5 INVITE Initate call to nic@home
When a call comes in,a pop-up window lets you know who's calling.
File Edit View Favorites Tools Help Enter a Name or Phone Number... Call
Lastname, First (123-4567)
Line 1001 Line 1002
SIP User Agent
Quick List
Enter a Name or Phone Number... Lastname, First (123-4567) Line 1001 Line 1002
79 People
People to Call
79 People
People to Call Friends (3 of 16 are online)
Friends (3 of 16 are online) Project Team (1 of 4 online)
Missed Calls
11 New Items
Henderson, Frank (234-5678) 2x Today 4:01p Unknown (234-5678) Lee, Bill (2342) Jones, Ralph (5411) Wilson, Pamela (2454) Today 3:11p Today 2:08p 2x Today 1:37p Today 12:59p
Brown, Bill (Available) Davidson, Karen (Busy)
6 Media
bernard@mitel.com
In the Office Im in a meeting
nic@home.com
Mitel Technology Primer
MITEL
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 Code 1XX Type Information Description
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).
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 Further action must be taken to complete the request Example: 301 Moved Permanently, 302 Moved Temporaily Request contains bad syntax Example: 400 Bad Request, 401 Unauthorized Request cannot be fulfilled at this server Example: 500 server Internal Error Request is invalid at any server Example: 600 Busy Everwhere
3XX
Redirection
4XX
Client error
5XX
Server error
6XX
Global failure
MITEL

3. SIP addressing
Because it is IP based, SIP provides users with globally reachable addresses. These addresses (URI) use the same format as an email address: user@domain, (e.g., nic@mitel.com or nic@24.7.91.19). 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: +1-925-242-4321. 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 email 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 users 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., 1-925-242-4321) 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 1.2.3.4.2.4.2.5.2.9.1.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, email, 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., 1-925-242-4321). 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
Proxy Server
1 Query 1.2.3.4.2.4.2.5.9.1. e164.arpa
2 Response SIP:nic.dufeu@ publicsip.net 3 INVITE
Proxy Server Proxy Server INVITE
User dials 1-925-242-4321
MITEL
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 Location Server
5 LS Query: B 3 INVITE Contact: A SDP A
6 Response: sip:B@2.3.4.5
Outbound Proxy Server 1 INVITE Contact:A SDP A
Inbound Proxy Server 4 100 Trying 7 INVITE Contact: A SDP A
2 100 Trying
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 Proxy Server
9 180 Ringing
Inbound Proxy Server
10 180 Ringing
8 180 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 Proxy Server
12 200 OK Contact: B SDP B
Inbound Proxy Server
14 ACK
User Agent A Media (RTP)
User Agent B
Diagrams above borrowed with modifications from Henry Sinnreich & Alan Johnston.
MITEL
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. 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 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 ITUs 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.
SIP
MGCP MGCP
RTP
Gateway
Gateway
MITEL
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: Proxy Server
CA: Call Agent (MGCP model) MG: Media Gateway (e.g., Nuera) MS: Media Server e.g., Convedia)
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 callers 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

File Edit View Favorites Tools Help
File Edit View Favorites Tools Help Enter a Name or Phone Number... Call
Enter a Name or Phone Number...
Call
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.
Line 1001 Line 1002
79 People People to Call Friends (3 of 16 are online) Project Team (1 of 4 online) Brown, Bill (Available) Davidson, Karen (Busy)
Line 1001 Line 1002
11 New Items Henderson, Frank (234-5678) 2x Today 4:01p Unknown (234-5678) Lee, Bill (2342) Jones, Ralph (5411) Wilson, Pamela (2454) Today 3:11p Today 2:08p 2x Today 1:37p Today 12:59p
Quick List
Auto Answer Call Forward Profile In the Office Im in a meeting Context sensitive instructional text displayed here...
79 People
People to Call Friends (3 of 16 are online) Project Team (1 of 4 online) Brown, Bill (Available) Davidson, Karen (Busy)
Message 200 OK
MITEL
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

PSTN
Class 5 switch
PRI
Broadband Network
Mitel 3600 ICP Server
Gateway
10 | Mitel Technology Primer
MITEL
SIP-Based Unified Messaging Deployment

Traditional Centrex Service Site #2
Traditional PBX PSTN digital IP/ VPIM Site #3 NuPoint UM - SIP IP WAN SMDI
T1
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.
| 11
MITEL
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.
IPC2 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
Voicemail
IP-VPN
Application Server Media Firewall
Other Application SoftSwitch
Branch Office
Remote Users
Video
MITEL
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
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).
SIP Server: B2BUA Implementation
Dialog #1: UAS Dialog initiated
Dialog #2: UAC Dialog initiated
User Agent 1
User Agent 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.
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?
| 13
MITEL
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, 802.11 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 vendors 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.
MITEL
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.). 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. For more on SIP, go to: www.voip-info.org/wiki-SIP www.cs.columbia.edu/sip/ www.cs.columbia.edu/sip/faq/ www.greycouncil.com/sipwg/ SIP WG Supplemental Homepage www.sipcenter.com/ The SIP Center www1.cs.columbia.edu/~xiaotaow/sipc/ UoColumbia SIP User Agent (sipc) www.ubiquity.net/products/SIP/SIP_User_Agent.php Ubiquity SIP user agent www.sipforum.com www.softarmor.com For more information or to evaluate Mitel SIP solutions, please contact your local Mitel Sales and Systems Engineer or visit our web site at http://www.mitel.com
| 15
MITEL
Acronyms
1xRTT 3G 3GPP AAA AG APCO AS ASP CDR CGALIES CLASS COR COS DTMF ENUM ETSI FQDN GK GPRS IETF IMP ISP IVR JAIN LDAP MG MGCP MPLS MS MSRP NAPTR NCS NENA NGN PA PUA PBX POTS PSTN QoS RFC Single Carrier Radio Transmission Technology Third Generation (wireless) 3G Partnership Project (UMTS) Authentication, Authorization and Accounting (IETF) Access Gateway Association of Public-Safety Communications Officials Application Server Application Server Provider Call Detail Recording Group on Access to Location Information by Emergency Svs Custom Local Area Subscriber Services, aka Custom Calling features Class of Restriction Class of Service Dual Tone/Multiple Frequency E.164 Numbering in DNS (IETF RFC 2916) European Telecommunications Standards Institute Fully Qualified Domain Name Gatekeeper General Packet Radio Service Internet Engineering Task Force Instant Messaging and Presence Internet Service Provider Interactive Voice Response Java Application Interface Network Lightweight Directory Access Protocol (IETF) Media Gateway Media Gateway Control Protocol (IETF, ITU-T J.162) Multi-Protocol Label Switching Media Server Message Session Relay Protocol Naming Authority Pointer Network Call/Control Signaling (PacketCable MGCP) National Emergency Number Association Next Generation Network Presence Agent Presence User Agent Private Branch eXchange Plain Old Telephone Service Public Switched Telephone Network Quality of Service Request For Comment (IETF)
MITEL
ROI RTCP RTP SCTP SDP SIMPLE SIP SIP-T SNMP SP SRV TDM TRIP UA URI VoIP VPIM XMPP
Return on Investment Real Time Transport Control Protocol (IETF) Real Time Transport Protocol (IETF RFC 1889) Stream Control Transmission Protocol Session Description Protocol (IETF RFC 2327) SIP Instant Messaging and Presence Leveraging Extensions Session Initiation Protocol (IETF) SIP For Telephony (IETF) Simple network management protocol Service Provider Server location records extension to DNS Time Division Multiplexing Telephony Routing over IP (IETF RFC 2871) User Agent Uniform Resource Indicator Voice over IP Voice Profile for Internet Mail 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) 592 2122 1 800 648 3579 Benelux Tel: +31 (0)30 85 00 030 Fax: +31 (0)30 85 00 031 Middle East Tel: +971 4 3916721 Fax: +971 4 3915288
Latin America (613) 592 2122 1 800 648 3579 Italy Tel: +39 02 2130231 Fax: +39 02 21302333 South Africa Tel: +27 82 559 8688 Fax: +27 11 784 6916
UK Tel: +44 (0)1291 430000 Fax: +44 (0)1291 430400 Germany, Switzerland, Austria Tel: +49 (0)211 5206480 Fax: +49 (0)211 52064899 Asia-Pacific Tel: +852 2508 9780 Fax: +852 2508 9232
France Tel: +33 (0)1 61 37 00 90 Fax: +33 (0)1 61 37 00 99 Portugal and Spain Tel: +34 91 350 66 33 Fax: +34 91 350 70 14
www.mitel.com
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 51008441RA-EN
Reference Material
The following is a list of reference materials on SIP.
Books

SIP Demystified. Gonzalo Camarillo, McGraw-Hill Telecom, ISBN 0-07-1373403 Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Sinnreich, Henry & Alan B. Johnston, John Weily & Sons, Inc., New York (c) 2001, ISBN 0-471-41399-2 SIP: Understanding the Session Initiation Protocol, Alan B. Johnston, Artech House, Boston, London, January 2001, ISBN 1-58053-168-7
Web-based Information

Session Initiation Protocol (SIP) http://www.cs.columbia.edu/sip The Internet Engineering Task Force (IETF) Web site http://www.ietf.org SIP Center http://www.sipcenter.com VOIP Wiki - a reference guide to all things VOIP www.voip-info.org/wiki-SIP The SIP Forum is an industry organization with members from the leading SIP technology companies. Its mission is to advance the adoption of products and services based on SIP. www.sipforum.com
White Papers
The following white papers are available from Mitel OnLine. Examining the Value of SIP in the Enterprise White Paper (PDF 238KB) SIP: Enabling Your Business to Leverage the Power of the Internet Customer Brief (PDF 273KB) SIP Interoperability List (PDF 77KB) SIP Technology Primer - Technical Overview (PDF 2.7MB) SIP Technology Primer - Value Proposition (PDF 490KB) 5215/5220 IP Phones (SIP functionality) Data Sheet - English (PDF 545KB)

MItel Technology Primer - SIP

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MItel Technology Primer - SIP

Uploaded by

Copyright:

Available Formats

MITEL

Technology Primer | SIP

Similarity to web protocols

High level description

Interaction with other protocols

SDP Applications SIP