Session Initiation Protocol Workshop

(1)

MITEL

Session Initiation Protocol

Workshop

3300 ICP

Product Release 9.0

(2)

NOTICE

The information contained in this document is believed to be accurate in all respects but is not warranted by Mitel Corporation (MITEL). The information is subject to change without notice and should not be construed in any way as a commitment by Mitel or any of its affiliates or subsidiaries. Mitel and its affiliates and subsidiaries assume no responsibility for any errors or omissions in this document. Revisions of this document or new editions of it may be issued to incorporate such changes

Inter-Tel® is a registered trademark of Inter-Tel (Delaware), Incorporated. Mitel® is a registered trademark of Mitel Networks Corporation.

Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or

redistribution to servers or lists, or to reuse any copy righted component of this work in other works must be obtained from Mitel Networks Corporation.

(3)

i

SIP Overview

PASTE TABLE OF CONTENTS FROM FIRST MODULE HERE

Mitel SIP

PASTE TABLE OF CONTENTS FROM SECOND MODULE HERE

SIP Phones

PASTE TABLE OF CONTENTS FROM THIRD MODULE HERE

SIP Trunks

PASTE TABLE OF CONTENTS FROM FOURTH MODULE HERE

Maintaining and Troubleshooting

PASTE TABLE OF CONTENTS FROM FOURTH MODULE HERE

Appendix

(4)

ii

Student Code of Conduct

Mitel University makes every effort possible to provide a safe, clean and professional

environment for students attending training classes. It has become necessary, for the benefit of all students, to define what is expected from those attending classes at Mitel University. Please observe the following guidelines.

Punctuality

Unless otherwise specified, all classes begin at 9:00 a.m. Students are required to return from breaks and lunch promptly, as the instructor specifies. Instructors will begin lectures promptly at the scheduled times.

Appropriate Behavior

Students are expected to participate in class as professionals. Disruptive behavior will not be tolerated.

Disruptive behavior is any action interfering with the instructor’s presentation or action distracting from another student’s ability to participate in the class. If, at the instructor’s discretion, a student is being disruptive, the following steps will be taken:

•

1st Occurrence: Verbal warning. The student will be advised that his or her behavior is

disruptive.

•

2nd Occurrence: Verbal warning. The student and the student’s manager or supervisor will

be informed that this is the final warning.

•

3rd and Final Occurrence: The student will be dismissed from the remainder of class and

the student’s manager or supervisor will be informed that the student has been released from class. The only option available to the student is to take the course exam at a

proctored testing center, at the student’s expense, or retake the course, in its entirety, at full tuition. No refund will be issued.

Training Equipment

Mitel University has made every effort to provide a “state-of-the-art” training facility and training equipment. Every effort has been made to provide the technology and equipment necessary to provide students with a real-world environment. All training systems and equipment (including PCs and the PC Network) are provided as tools to enhance the training experience. Equipment is only to be accessed and utilized for the completion of class lab exercises as the instructor indicates. Unauthorized exploring of, or experimenting with the training equipment will be considered disruptive behavior and will not be tolerated.

Leaving Class Prior to the Final Certification Exam

Occasionally, a student may have a bona fide reason to leave class early due to a family emergency, death in the family, etc. If a student must leave class prior to the administration of a final written exam for any reason, the only option available to the student is to complete the final written exam at a proctored testing center. Testing fees from the testing center are the

(5)

iii

Course Description

This practical workshop provides the student with hands-on experience of the Session Initiation Protocol (SIP) and its uses within the telecommunications environment. The workshop focuses on how Mitel implements SIP within an array of end user devices, intersystem trunks, external applications and Internet Telephony Service Provider trunks. It provides details of monitoring and troubleshooting devices and trunks by focusing on network packet captures.

Objectives

At the completion of the course you will be able to:

•

Implement and configure SIP based phones on a Mitel 3300 ICP

•

Implement and configure SIP trunks between Mitel 3300 ICPs and to a variety of 3rd Party providers.

•

Monitor and troubleshoot a SIP registration and trunk communication

Audience

The audience for this course is Mitel 3300 ICP engineers who have an understanding of the 3300 ICP platform, a working knowledge of Voice over IP communications and who want to improve their understanding and practical knowledge of the Session Initiation Protocol.

(6)

iv

Resources

During this course, you will be referring to the following resources:

•

Course Manual

•

Additional Software

(7)

SIP Overview

Objectives

When you finish this module, you will be able to:

Describe the components associated with SIP Describe the workings of SIP

(8)

(9)

1- 3

Introduction

SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions. It is an Internet standard published originally in March1999 as RFC 2543, but later superseded by RFC 3261 in June 2002. The primary function of SIP is to initiate and control sessions; communication channels between two or more devices. SIP can invite participants to already existing sessions and can also add or remove media from sessions. SIP is independent of the underlying transport protocols.

SIP does not provide any services. It provides the framework for other protocols to use in order to establish a complete architecture. These protocols may include the Real-time Transport Protocol (RTP) (RFC 1889) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327) for describing multimedia sessions. However the basic functionality and operation of SIP does not depend on any of these protocols.

SIP is based on a request and response transaction model similar to HTTP. Each transaction consists of a request that invokes a particular method or a function on the server and at least one response.

SIP provides the capabilities to:

•

Determine the location of the target end point – SIP supports address resolution, name mapping, and call redirection.

•

Determine the media capabilities of the target end point – Via Session Description Protocol (SDP), SIP determines the “lowest level” of common services between the end points. Conferences are established using only the media capabilities that can be supported by all end points.

•

Determine the availability of the target end point – If a call cannot be completed because the target end point is unavailable, SIP determines whether the called party is already on the phone or did not answer in the allotted number of rings. It then returns a message indicating why the target end point was unavailable.

•

Establish a session between the originating and target end point – If the call can be completed, SIP establishes a session between the end points. SIP also supports mid-call changes, such as the addition of another end point to the conference or the changing of a media characteristic or codec.

•

Handle the transfer and termination of calls – SIP supports the transfer of calls from one end point to another. During a call transfer, SIP simply establishes a session between the transferee and a new end point (specified by the transferring party) and terminates the session between the transferee and the transferring party. At the end of a call, SIP terminates the sessions between all parties.

(10)

SIP Entities

A SIP network is composed of four types of logical SIP entities. Each entity has specific functions and participates in SIP communication as a client (initiates requests), as a server (responds to requests), or as both. One “physical device” can have the functionality of more than one logical SIP entity. For example, a network server working as a Proxy server can also function as a Registrar at the same time.

Following are the four types of logical SIP entities:

USER AGENT

In SIP, a User Agent (UA) is the endpoint entity. User Agents initiate and terminate sessions by exchanging requests and responses. RFC 3261 defines the User Agent as a logical entity that can act as both a user agent client and user agent server, as follows:

•

User Agent Client (UAC) – a client application that initiates SIP requests.

•

User Agent Server (UAS) – a server application that contacts the user when a SIP request is received and that returns a response on behalf of the user.

Some of the devices that can have a UA function in a SIP network are: workstations, IP-phones, telephony gateways, call agents, automated answering services.

PROXY SERVER

A Proxy Server is an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced either internally or by passing them on, possibly after translation, to other servers. A Proxy interprets, and, if necessary, rewrites a request message before forwarding it.

REDIRECT SERVER

A Redirect Server is a server that accepts a SIP request, maps the SIP address of the called party into zero (if there is no known address) or more new addresses and returns them to the client. Unlike Proxy servers, Redirect Servers do not pass the request on to other servers.

REGISTRAR

A Registrar is a server that accepts REGISTER requests for the purpose of updating a location database with the contact information of the user specified in the request.

(11)

1- 5

Messages

There are two types of SIP messages:

•

Requests – sent from the client to the server.

•

Responses – sent from the server to the client.

REQUESTS

A request invokes a particular method, or function, on the server and at least one response.

Request Methods

Method Description

INVITE Initiates a call, changes call parameters (re-INVITE)

ACK Confirms the final response for INVITE

BYE Terminates a calls

CANCEL Cancels searches and ‘ringing’

OPTIONS Queries the capabilities of the other side

REGISTER Registers with the Location Service

INFO Sends mid-session information that does not modify the session

state

RESPONSES

Response messages contain numeric response codes. The SIP response code set is partly based on HTTP response codes. There are two types of responses and six classes:

RESPONSE TYPES

•

Provisional (1xx class) – provisional responses are used by the server to indicate progress, but they do not terminate SIP transactions

•

Final (2xx, 3xx, 4xx, 5xx, 6xx classes)—final responses terminate SIP transactions. CLASSES

•

1xx = provisional, searching, ringing, queuing etc.

•

2xx = success

•

3xx = redirection, forwarding

•

4xx = request failure (client mistakes)

•

5xx = server failures

(12)

Example Response Codes

Method Description

100 Trying 180 Ringing 181 Call Is Being Forwarded

182 Queued 183 Session Progress

200 OK

300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily

305 Use Proxy 380 Alternative Service

400 Bad Request 401 Unauthorized 402 Payment Required

403 Forbidden 404 Not Found 405 Method Not Allowed

406 Not Acceptable 407 Proxy Authentication

Required

408 Request Timeout

410 Gone 413 Request Entity Too

Large

414 Request-URI Too Long

415 Unsupported Media Type 416 Unsupported URI Scheme

420 Bad Extension

421 Extension Required 423 Interval Too Brief 480 Temporarily Unavailable

481 Call/Transaction Does Not Exist

482 Loop Detected 483 Too Many Hops

484 Address Incomplete 485 Ambiguous 486 Busy Here

487 Request Terminated 488 Not Acceptable Here 491 Request Pending

493 Undecipherable

500 Server Internal Error 501 Not Implemented 502 Bad Gateway

503 Service Unavailable 504 Server Time-out 505 Version Not Supported

513 Message Too Large

600 Busy Everywhere 603 Decline 604 Does Not Exist

Anywhere 606 Not Acceptable

MESSAGE PARTS

SIP messages are composed of the following three parts:

START LINE

Every SIP message begins with a Start Line. The Start Line conveys the message type

(method type in requests, and response code in responses) and the protocol version. The Start Line may be either a Request-line (requests) or a Status-line (responses), as follows:

•

The Request-line includes a Request URI, which indicates the user or service to which this request is being addressed. This address can be re-written by proxies.

(13)

1- 7

HEADERS

SIP header fields are used to convey message attributes and to modify message meaning. They are similar in syntax and semantics to HTTP header fields (in fact some headers are borrowed from HTTP) and thus always take the format:

Headers can span multiple lines. Some SIP headers such as Via, Contact, Route and Request-Route can appear multiple times in a message or, alternatively, can take multiple comma-separated values in a single header occurrence.

BODY (CONTENT)

A message Body is used to describe the session to be initiated (for example, in a multimedia session this may include audio and video codec types, sampling rates etc.), or alternatively it may be used to contain opaque textual or binary data of any type which relates in some way to the session. Message bodies can appear both in request and in response messages. SIP makes a clear distinction between signaling information, conveyed in the SIP Start Line and headers, and the session description information, which is outside the scope of SIP.

Possible body types include:

•

SDP—see Session Description Protocol (SDP).

•

Multipurpose Internet Mail Extensions (MIME).

(14)

SIP Transactions

A SIP Transaction consists of a number of messages that are sent and responded to in order to establish a session.

A typical transaction will proceed as follows:

INVITE ---> 100 Trying <--- 180 Ringing <--- 200 OK <--- ACK ---> Communication Å---Æ BYE ---> 200 OK <--- Session Establishment

1. The calling User Agent Client (UAC) sends an INVITE message to the User Agent Server (UAS). This message contains a Request URI and an SDP packet describing the media capabilities of the calling terminal.

2. The UAS receives the request and immediately responds with a ‘100 Trying’ response message.

3. The UAS starts ringing to inform the user of the new call. Simultaneously a ‘180 Ringing’ message is sent to the UAC.

4. The call is answered and the UAS sends a ‘200 OK’ message to the UAC. This

message also contains an SDP packet describing the media capabilities of UAS device. 5. The UAC sends an ACK request to confirm that the ‘200 OK’ response was received.

The session is established and other protocols, as described in the SDP Packet, are used to send the communication to each party.

Session Termination

1. The caller decides to end the call and hangs-up. This results in a BYE request being sent to the UAS. The Message contains the Request URI used in the INVITE message.

User Agent Server UAS

User Agent Client UAC

(15)

1- 9

2. The UAS responds with ‘200 OK’ message and notifies the user that the conversation has ended.

As more devices are added to the network, the transactions become more involved and details can be changed at various levels.

The next example shows how a proxy server can be used between the two user agents:

INVITE ---> 100 Trying <--- 180 Ringing <--- 200 OK <--- Communication <--- BYE ---> 200 OK <--- INVITE ---> Trying <--- Ringing <--- 200 OK <--- Communication ---> BYE ---> 200 OK <---

This call flow shows how a Proxy Server can pass requests from one user agent to another. User Agent Server UAS User Agent Client UAC Proxy Server Proxy Server

(16)

Session Description Protocol (SDP)

SDP is the protocol used to describe multimedia session announcement, multimedia session invitation and other forms of multimedia session initiation. A multimedia session is defined, for these purposes, as a set of media streams that exist for a duration of time.

SDP PACKETS

SDP packets usually include the following information:

Session information

•

Session name and purpose.

•

Time(s) the session is active.

Since the resources necessary for participating in a session may be limited, it would be useful to include the following additional information:

•

Information about the bandwidth to be used by the session.

•

Contact information for the person responsible for the session. Media information

•

Type of media, such as video and audio.

•

Transport protocol, such as RTP/UDP/IP and H.320

•

Media format, such as H.261 video and MPEG video.

•

Multicast address and Transport Port for media (IP multicast session).

(17)

1- 11

;

Lab 1 – Viewing SIP Packets in Wireshark

In this lab you will:

View a Wireshark capture of a SIP Session

Note

To complete this lab, you will need to have Wireshark installed. For details on Wireshark, please see Appendix B

View a Wireshark Capture

Step Task Expected Result/Observation 9

1 Browse to and open C:\Mitel Academy\Mitel SIP Workshop\SIP Trace 1.pcap

2 Select the textbox next to ‘Filter:’ Type sip and press Enter

This will filter all other packets leaving only SIP packets in the view.

3 Select Statistics > VoIP Calls

4 Select the call from the list and click Graph The graph shows a graphical

representation of the SIP Transaction

5 Select each SIP message in turn (not the RTP packets) and view the details in the Packet Details section of the Wireshark tool

6 Close the Graph and VoIP Calls windows Remove the filter and look at the RTP Packets

How many packets are there per second?

7 Close SIP Trace 1 and open SIP Trace 2

Repeat the exercise, this time try to figure out what is happening with the two calls

(18)

Mitel SIP

Objectives

Describe the workings of the Mitel SIP Compliance Program and the SIP Centre of Excellence

Download the latest Interop Reference Guide

(19)

(20)

SIP Compliance Program

In order to achieve best results, Mitel has created a SIP Compliance Program where service Providers, endpoints, gateways, firewalls, applications servers and enterprise SIP Servers can be tested according to defined standards to ensure compatibility.

There are four levels:

Mitel Approved

Reserved for MSA Gold Preferred members only, this rare classification is reserved for key strategic components of our portfolio for which Mitel assumes the full responsibility for support, acting as the interface between the customer and the 3rd party as necessary.

Compatible

The most common certification which means the device/service has been tested and/or

validated by the Mitel SIP CoE team. Product support will provide all necessary support related to the interop, but issues unique or specific to the 3rd party will be referred to the 3rd party as appropriate.

3

rd

Party Self-Assessed

Denotes that the 3rd party provider of the device/service has performed the interop testing they deem necessary and has asserted to Mitel that the interop was successful. All support related to the interop is referred directly to the 3rd party, as they are the ones making the assertion of compatibility, not Mitel.

Field-Assessed

For informational purposes only, field-assessed means that the device/service has been tested and/or used to some degree by someone successfully, though details may or may not be available. Mitel product support does NOT apply to field-assessed interops.

Note

(21)

2- 4 Module 2 Mitel SIP

SIP Centre of Excellence

The SIP Centre of Excellence is a team of people dedicated to ensuring that Mitel continues to lead in SIP implementation, by innovating and testing new ideas, features and programs.

In order to accomplish the goal of interoperability, Mitel have devised strict testing scenarios and guidelines that should be followed. These guidelines are available on Mitel OnLine and are composed of two sections namely SIP Phones and SIP Trunking.

The following diagram shows the test plan that is used for SIP Trunks

The tests cover a wide range of scenarios and include, among other tests:

•

Basic Outgoing and Incoming

•

Outgoing and Incoming Failures

•

ONS, LS Trunks and PRI Interoperability

•

Registration and Authentication

•

Provisional Responses

•

Privacy, Codecs, Hold, DTMF, FAX

•

Transfers and Conferencing

(22)

Once test cases are performed and traces obtained, the details should be sent to

(23)

2- 6 Module 2 Mitel SIP

SIP endpoint (lineside) resiliency

At present, there are no clear SIP standards for SIP resiliency that would be comparable to what is achieved in a proprietary implementation for devices connected to a 3300 ICP solution using MiNET such as the Mitel 5304 / 5312 / 5324 / 5330 and 5340 IP Phones. As such, Mitel’s implementation features different levels of SIP resilient behaviour, ranging from basic resiliency in accordance with current specifications to resiliency comparable to what is achieved under MiNET. The level of resiliency supported is determined primarily by the capabilities of the endpoint.

The four levels of resiliency available are: Bronze, Silver, Gold and Platinum.

The lower levels are possible with generic SIP endpoints through device configuration, but have longer failure detection times. The more advanced resiliency levels require specific

development and signal handling on the endpoint to support the Mitel model.

In all cases, successful resilient behaviour cannot be assumed, but instead must be tested explicitly to ensure successful interoperation between the device and the ICP. Starting with MCD 4.0, the SIP Center of Excellence will include resiliency testing as part of all 3rd party lineside interoperability.

Feature Enhancements

SIP Resiliency refers to continued service from a SIP endpoint despite the endpoint being unable to reach its primary 3300 Controller.

Even though the secondary remains available, when the primary is capable of resuming service for the device, the device should fail-back to its primary and re-establish service.

The process of fail-over and fail-back needs to be transparent to the end user, but the time it takes for a device to fail-over and fail-back will vary widely depending on the resiliency model supported by the device. While calls can be placed to the device at any time, calls from the device cannot be handled until such time as the device recognizes its proper controller.

Note

SIP Resiliency, in this context, does not refer to resiliency related to SIP trunking

Because the capability is as much associated with the endpoint as it is with the 3300 Controller, Mitel is not in control of all aspects of resilient behaviour. For a device to be resilient within any service model, standard programming is required on the 3300 controller and the SIP device must also accept and respond to SIP messages from any IP address, not just the address with which it has registered. This allows the 3300 Controllers to dynamically adjust the signalling path when a failure occurs, thereby routing incoming calls virtually instantly to the SIP device (the default configuration for out-of-service time for incoming calls is 45 seconds).

Because of the need for capabilities in the endpoint there are multiple levels of SIP resiliency possible on the 3300 controllers.

(24)

Bronze

The Bronze level of resiliency relies on DNS to provide the SIP device with an alternate address should the primary address become unreachable. There are two events which would trigger the registration with the secondary 3300 Controller. The registration refresh timer expires, and the endpoint, upon failing to register with the unavailable primary 3300 Controller, automatically initiates registration with the secondary 3300 Controller.

Alternatively, if a user attempts to make a call, the endpoint will be unable to communicate with the primary 3300 Controller and will then register with the secondary in order to place the outgoing call.

The time to detect loss of service from the primary 3300 Controller and fail-over to the secondary 3300 Controller is dependent on either registration refresh or user interaction. To minimize the failure detection time, the registration refresh interval can be lowered, to not less than 300 seconds. Otherwise, the resulting network traffic from set registration effects can impact total call volume scalability.

If a device supports the 301 REDIRECT message on REGISTER, and also supports the concept of reconfiguring all services to the IP address the device registers with, the device will seamlessly fail-back to the primary 3300 Controller once it is available. If not, the device will need to support the priority entry for DNS entries, as well as periodically retry higher priority entries. The DNS server will need to be programmed with the Primary 3300 Controller having a higher priority in order to guarantee the Primary 3300 Controller is the primary service provider.

A phone cannot be considered resilient unless it provides some form of implementation to return to the primary 3300 Controller (fail-back) once it is available

Silver

The Silver level of resiliency allows the primary and secondary 3300 Controller to be specified using static provisioning on the device. The device may support the use of 301 REDIRECT, which can further improve the configuration experience by allowing the device to be redirected into the MCD cluster when it’s primary or secondary is reconfigured on the 3300 Controller.

When the SIP device detects that the primary ICP is no longer reachable, which typically occurs via REGISTER refresh or user action (e.g. make a call), the device will attempt to communicate with the secondary. In the event of static provisioning, this may result in a 301.

Gold

The Gold level of resiliency encompasses all the capabilities of the silver model, with the addition that the phone is capable of using a SIP OPTION message as a heartbeat. By using a heartbeat message, the endpoint does not have to wait for the registration refresh timer to expire before detecting the failure of the primary ICP. Consequently, the registration refresh timer can be set to the recommended 60 minutes. Processing the OPTION message requires much less CPU overhead than processing the REGISTER message.

Platinum

The Platinum level of resiliency provides the best level of resiliency protection. The primary and secondary 3300 Controller information is provided dynamically to the phone via proprietary SIP headers. The interval for the OPTION heartbeat is also specified in this message.

(25)

2- 8 Module 2 Mitel SIP Summary of Levels

Level Pros Cons Example of Device in

this category

Bronze No additional implementation required by the SIP device.

Fail-back depends on device implementation. Requires frequent registration refresh interval to limit out-of-service period.

Third party SIP devices that correctly support DNS- based registration. Mitel SIP endpoints;

Polycom® SoundPoint®

IP301 and IP430

Silver Ease of configuration (can provision static entry points which then issue 301 REDIRECT messages upon registration).

Fail-over and fail-back still depends on the registration refresh interval.

Ascom IP DECT

Gold By using the OPTION message, failover detection time is improved

considerably.

The ICP has no control over the frequency of the OPTION message

–

Platinum Very fast fail-over and failback detection times.

The phone requires no additional configuration to support resiliency.

The primary and secondary ICPs can be reconfigured dynamically, and the phone automatically detects and adapts.

Requires the phone to support a proprietary header.

(26)

Lab 1 – Download the latest SIP Interop Reference

1 Open and login to Mitel OnLine

2 Select Knowledge Base from the Technical section

3 Select 3300 Integrated Communications Platform ICP from the product drop down list.

4 Search using the keywords “SIP Interop”

5 Select the latest SIP Interop reference document

6 Click the pdf icon representing the document The pdf documents opens.

(27)

SIP Phones

Objectives

Program and connect a 3rd

Party SIP Phone to MCD 4.0 Configure a Mitel IP Phone in SIP mode and connect it to a 3rd

Party SIP Server

Connect a Mitel 5302 SIP phone to MCD 4.0

(28)

(29)

3- 3

SIP Phone Support

With generic SIP Phone support in the 3300 ICP, SIP endpoints can utilize the rich functionality provided by the 3300 ICP. This capability allows the creation of multi-vendor solutions based on open standards and ensures a natural fit of SIP Phones into the 3300 ICP management

paradigm.

SIP Phone support offers the following features:

Registration and Authentication

SIP devices must register with the 3300 ICP using the SIP Register method as described in RFC3261. Registration cannot occur unless the device has been configured.

Authentication can be enabled on a per SIP device basis. If authentication is enabled, the SIP device will be challenged as per RFC3261 during registration and while making calls (on SIP REGISTER and INVITE methods).

Billing and SMDR

All calls from Generic SIP phones are represented in SMDR as calls from local extensions.

Licensing

Every generic SIP Phone requires a SIP user license in order to be configured. Device licenses will not be required for the SIP phone to operate.

3300 ICP Management and Configuration

SIP Phones are configured within the 3300 ICP, similar to Multiline sets and Hotdesk users. Each SIP phone has a main DN associated with it. Additional lines can be programmed for the SIP Phone allowing calls for alternate DNs to be delivered to the SIP Phone.

Additionally, the behavior of a given SIP device can be characterized using the SIP Device Capabilities Assignment form and then applied to SIP phones to support alternate capabilities. Support for CESID and peer trunk status is available between the 3300 ICP and third-party devices.

Note

Mitel does not recommend that Mitel dual mode sets be deployed in SIP mode on the 3300 ICP because in SIP mode the set provides significantly less functionality than it does in MiNET mode.

(30)

Generic SIP Devices MCD 4.0

The following features are supported via defined SIP methods between 3300 ICP and Generic SIP Endpoints:

Basic Call

All SIP devices must be registered with the 3300 ICP, which acts as the Registrar. Once registration is completed, SIP devices can make and receive calls. Calls made to an unregistered SIP device will fail, similar to calls placed to a non-existent IP device.

Calls made from a SIP device that has not registered with the 3300 ICP will receive SIP error message 404 - Not Found.

Note

When a handset is out of range or switched off, calls from other phones to that extension provide ringback instead of overflow tone. This behavior applies to KIRK sets and to wired SIP sets that are unplugged.

Broadcast Group

SIP users can participate in all different kinds of groups and have the same restrictions as MiNET sets.

Call Forward

The Generic SIP Phone can have Call Forwarding options programmed against its DN. The programming of call forwarding destinations, as well as the activation and deactivation of call forwarding, is performed using feature access codes. In addition to supporting the 3300 ICP forwarding behavior, SIP phones can also provide local call forwarding directly from the set using SIP REDIRECT messages defined in RFC 3261.

Call Hold

SIP devices can place a call on hold and music may be provided by their endpoint.

Call Hold Retrieve

The SIP user can retrieve the held party by dialing the feature access code for Call Retrieve.

Call Park and Call Park Retrieve

Calls can be parked against the user DN and retrieved by using the Call Park Retrieve feature access code.

(31)

3- 5

Call Transfer

The 3300 ICP provides RFC compliant SIP signaling support for blind (unattended) and supervised (attended) transfers. Blind transfer is based on the REFER method defined in RFC 3515. Supervised transfers rely on the "Replaces" header defined in RFC 3891, and allows the following:

CANCEL transfer operation and reversion back to the original caller (in case of Mitel SIP phone, the Cancel key can be used). This must be accommodated during the ringing and answered states.

RELEASE transfer resulting in the connection of the current and held party.

TRADE between two calls

CONFERENCE between parties involved in the transfer

Calling Party Number and Name

The name and number of the calling party is present to the SIP phone at setup time, if

available. If the call originated on a 5ESS PRI trunk, the calling name and number may not be available.

When the SIP Phone initiates a call, the name and number supplied in the FROM header will be used as the calling party name and number.

Conference

SIP phones support the following forms of conference:

Locally hosted conference (if supported by the device - this requires enabling Multiple Line Support in the SIP Device Capabilities form)

Conference bridge

Conference hosted on a conference resource known to the 3300 ICP (3300 ICP hosted conference is only available if Multiple Line Support is disabled in the SIP Device Capabilities form)

Connected number delivery

When a SIP user makes a call to the 3300 ICP, the current number and name being alerted is displayed (wait for answer display). When the call is answered, it may not be answered by the same number that was presented to the caller in wait for answer state. If this is the case, then the answering party's name and number are displayed to the caller.

For example:

A calls B

C has an appearance of B

(32)

C answers the call and the answer message contains C's name and number.

Dialed Call Pickup

SIP users can be members of a Pickup group. When a member in the groups is ringing and the SIP device can pick up the call using the Dialed Pickup feature access code.

Directed Call Pickup

SIP devices can pick up calls by using the Directed Call Pickup feature access code and the DN of the device to be picked up.

Do Not Disturb

SIP devices can activate Do Not Disturb by dialing the Do Not Disturb feature access code.

DSS/BLF

Other devices in the network can be configured to monitor the SIP device. The DSS/BLF behavior is limited when a SIP device is being monitored. On and off-hook events, and certain key presses in some cases are not monitored.

Emergency Support for Generic SIP Phones

This feature provides the following improvements:

Caller Emergency Service Identification (CESID) when a generic SIP phone makes an emergency call. The information provided is an ID number and if programmed, a comment. If no comment is programmed for the device, then the emergency caller's telephone directory name is displayed.

An SNMP event is generated to the Emergency Response Advisor when a generic SIP phone makes an emergency call. The CESID number in the SNMP event must be the default CESID number or a programmed CESID number for the generic SIP phone.

Emergency Services - Location Notification is also supported on Generic SIP Phones.

Feature Access Keys

Generic SIP Phones: While users are logged into a SIP device, feature access keys that are available on MiNet sets will not be accessible—for example, Call Forwarding, Message

Indication Key, Auto Answer, and so forth. Some of these features may already be provided by the SIP phone itself.

The administrator can assign any specific usage for programmable keys, since they are not defined. The key assignment shown below is an example only.

5302 SIP Phones: The 5302 SIP Phone has four programmable keys that are hard coded as CDE Speed Calls, which can be programmed in the System Administration Tool to provide the following features:

(33)

3- 7

Key #3 – Voicemail Key #4 – Conference

Key #5 – Personal Speed Call 1 Key #6 – Personal Speed Call 2

Hunt Group

SIP users can be members of a hunt group and calls are presented to the SIP device as they normally would to the MiNET user.

Key Line Appearance

With the exception of the 5302 SIP Phone, a SIP device may have the line appearances of other devices, or broadcast groups in the system.

Last Number Redial

SIP devices can use Last Number redial by using the appropriate feature access code.

Message Waiting Indication for Voice Mail Integration

Message Waiting indications are only provided for the prime line associated with the Generic SIP phone user.

Paging (Direct, Group, and Loud Speaker)

A SIP phone can initiate a direct page using the Direct Page feature access code and the DN of the device to be paged. The regular COS checks apply. SIP devices can perform loudspeaker pages to specific zones or all zones by using the feature access codes.

Persistent Registration of Non-Resilient SIP Devices

If the 3300 ICP reboots, either due to a planned upgrade or unplanned occurrence such as a power outage, the 3300 ICP remembers the registration information for non-resilient SIP devices and automatically re-creates the registrations. This allow the SIP devices to place and receive calls without having to wait for the devices to re-register on their own at some later time.

Registration of SIP Endpoints with Name

This feature supports using name strings in the URI; an Internet style address, such as sip:[email protected]. The feature uses the URI/Number translation table configured by the system administrator.

Remote Hold Retrieve

SIP devices may retrieve held calls, which reside on other devices by dialing the Remote Hold Retrieve access code. When the SIP device places a call on hard hold, others in the system can pick the call up.

(34)

System Speed Call

SIP devices can initiate a system speed call by dialing an abbreviated Speed Call Number.

Note

(35)

3- 9

Program Generic SIP Phones

To program generic SIP telephones, use the following forms:

SIP Device Capabilities Assignment

To program the generic SIP device as a multiline set, enable the "Replace System based with Device based In-Call Features" field. Complete the other fields as required. Additionally, at least one of the keys of the SIP device must be configured as Multicall to its own prime DN or Key System to another DN in the Multiline Set Key Assignment form.

Multiline IP Set Configuration form

Complete the Device Type, Directory Number, User PIN, Confirm User PIN, Interconnect Number, and Tenant Number fields.

The device type must be "Generic Device Type".

Login PIN is the SIP authentication password. The username is the DN.

Set this option to program as a multiline set

(36)

Multiline Set Key Assignment form

To program a generic SIP device as a multiline set, program additional buttons with a Line Type of "Multicall." Enter the directory number of the generic SIP device in the Button Directory Number field. Note that entering numbers others than DN of the device is not supported.

(37)

3- 11

Multiline Set Group Assignment form (Optional)

Change the ring type at each telephone where this number appears.

Change the group type from "key system" to "multicall" or vice versa.

Default Account Code Definition form (Optional)

Create a default account code number that will appear in all SMDR records for the station.

Station Service Assignment form

Assign a Class of Service, Class of Restriction, and Intercept Number to the directory number of the telephone. Change the SIP Device Capabilities number, if applicable.

(Optional) Assign a Default Account Code Index number.

User Configuration form

Use the User Configuration search field to locate the directory number that you assigned to the device. Assign a name, department, and location to the directory number. Enter the SIP Device Capabilities number, if applicable.

Shared Forms Configuration

Ensure that the SIP Device Capabilities form is shared. The default is "All Cluster Members." You can also restrict records from being shared by specifying the SIP Device Capabilities Numbers not to share in "Records Not Shared" portion of the form.

Class of Service Options

Set "Public Network Access via DPNSS" to Yes in the COS of SIP Phones to allow calls over LS trunks.

Disable the Auto Camp-on Timer to allow unsupervised call transfers from the SIP device to camp on to busy station.

Note

If no telephone directory name is programmed for a SIP device on the 3300 ICP, the system will default to the SIP display name. For some SIP devices, the SIP display name can be provisioned. To prevent users of generic SIP devices from programming their own display name, you should always add an entry and provide a name for all of these devices in the Telephone Directory Assignment form.

(38)

If you delete telephones, you must also delete the corresponding directory entries and voice mailboxes.

URI/Number Translation (Optional)

The URI/Number Translation form will allow a name to be substituted for a number if this is required. The outgoing number of the Mitel system is replaced with the host portion of the SIP URI.

Example: “[email protected]” will become “[email protected]” for outbound calls, similarly “[email protected]” will become “[email protected]” for inbound calls

(39)

3- 13

;

Lab 1 – Connecting a 3

rd

party SIP phone to a Mitel

controller

Connect the X-lite softphone, a 3rd

party SIP softphone, to the Mitel controller

Configure a Generic SIP device on the 3300

1 Open the 3300 System Administration tool for the controller

2 Navigate to System Configuration > Devices > SIP Device Capabilities Assignment form

3 Select number 3 in the right-hand pane Click Change

4 Fill in the form:

Comment: X-Lite softphones

Click Save

5 Navigate to System Configuration > Devices > User Configuration

6 In the right-hand pane, click the add button and fill in the details as follows:

Last Name: Tom

First Name: Gray

Number: x002, where x is your student id

Device Type: Generic SIP Phone SIP Device Capabilities: 3

User Pin: x002, where x is your student id Confirm User PIN: as above

Desktop Admin: Remove the tick

Click Save

Consult your instructor for the Class of Service and Class of Restriction values.

(40)

Install and configure X-lite

8 Open C:\Mitel Academy\SIP Workshop folder

Double click X-Lite Setup.exe to begin the installation

A wizard appears to guide you through the installation

9 Click Next

Agree to the License Agreement, click Next Leave the default path, click Next

Leave the default options selected, click Next Leave the ‘Launch X-Lite’ option selected, click Finish

10 Answer any question that might be displayed until X-Lite shows the ‘SIP Accounts’ dialog box

11 Click the Add button on the right and fill in the form:

Display Name: Tom Gray

Username: x002, where x is your student id

Password: x002, where x is your student id

Domain: IP Address of the controller

eg 192.168.y.2, where y is you subnet id Click OK

Click Close

You should see X-Lite display Registering….

Then Ready

Your username is: x002

(41)

3- 15

Mitel SIP software of IP Phones

Mitel has been working with SIP for years. Over that time many changes and improvements have taken place. At the time of writing this course the most recent version of SIP software was 7.2 UR1.

To check if there is a newer version, login to the Mitel website and check in the Software downloads section.

Note

Information on updating the phone to the latest version of SIP will be covered later in the course.

(42)

Changing to SIP Mode

By default Mitel phones1 arrive ready to work using the Minet protocol. To change this behaviour the phone will need to be configured.

The easiest way to do this is to boot the phone whilst holding down the * and 7 buttons

You will see:

then

To return the set to MiNET mode, hold down * and 6 during boot up.

If the phone is already loaded the Firmware Menu can be used

To do this press both the up and down volume buttons at the same time, then while keeping one button down, release the second button. Still holding the remaining volume button down, dial 234 and then let go of the volume button.

The following screen will be displayed:

Changing a Mitel phone mode to SIP

Display What to press Display What to press

Press

#

Press

#

Press

*

Press

*

Press

*

Press

0

Press

#

Press

*

1 Mitel 5302 only communicates using the SIP protocol. CHANGE CONFIRMED MODE CHANGE TO SIP

Release keys=cancel

STORE CHANGES?

*=YES #=NO PHONE MODE: SIP

*=Change #=Accept

PHONE MODE: Minet

*=Minet 0=SIP #=Back

HARDWARE CONFIG? *=YES #=NO NETWORK PARAMETERS? *=YES #=NO PROTOCOL? *=YES #=NO

PHONE MODE: Minet *=Change #=NoChange PHONE MODE?

*=YES #=NO NETWORK PARAMETERS? *=YES #=NO

(43)

3- 17

Wait Wait

Press

*

Wait

Once the phone has rebooted, it can be configured through the web interface. REBOOT NOW? Resetting Phone… REBOOT NOW?

*=YES #=NO

NVRAM SAVE COMPLETE SAVING TO NVRAM

(44)

Configuring a SIP mode Mitel IP Phone – Quick Setup

To configure a Mitel IP phone, browse to the IP address of the phone using Internet Explorer. Example: http://192.168.1.20

The default User name is admin and the password is the model of the phone. Example: If I am configuring a Mitel 5340 IP Phone, the username is admin and the password is 5340.

Once Logged in you will see the Home page

For a basic setup, select the Quick start menu from the left column

(45)

3- 19

Fill in the User ID or Extension, User Display name, SIP Authentication User name and SIP Authentication Password.

Fill in the FQDN or IP Address for the SIP Proxy Server and the SIP Registrar Server.

Click on Apply.

The phone will automatically create a user account, which will allow the user to log in using their extension number (username) and SIP Authentication Password (password). This will enable the user to change personal setting for the phone.

(46)

Detailed look at the SIP Configurations

Home

(47)

3- 21

Admin Tools

Quick Start

Unique name or extension number assigned to the user.

Maximum of 32 characters.

Name displayed on a user's phone. Maximum of 20 characters.

User's SIP account name and password from your SIP Service

Provider.

Required only if you have a SIP Service Provider. If you do not have a SIP Service Provider, password is used to log in.

The IP Address or FQDN is appended to dialed name or number. Maximum of 128 characters

(55)

3- 29

User List

User Configuration Screen

Click the Add New button to create a new user. The User Configuration screen opens in a new window

The top part is the same as the Quick Configuration

SIP request and responses are sent to the outbound server.

If set to Default, only the first packet is sent to the outbound server. If set to All Packets, then all packets are

sent to the outbound server.

Server IP address and domain name of external voice mail server. If this

field is configured, the phone will connect to server using the default

user name during boot-up.

When Keep Alive mode is configured, if UDP is configured, Mitel SIP phones send STUN keep alive packets to the SIP Registrar

(or Proxy, if Registrar field is empty). IF TCP connection is configured, phones send TCP carriage returns.

(56)

Advanced Features

Time after which the phone will automatically re-register with the Registration Server. This can be used for resiliency. None = no registration authentication.

Basic = authentication with basic encryption. Digest = authentication with digest encryption.

Set the SIP session timeout value (in seconds). If the peer does not respond within the allocated

time, the session (call) will be torn down. URL of voice mail server. If this field is configured, the phone will

connect to server using the default user name during boot-up. long

SIP-Contact (RFC3840)

When changing from one language to another, make sure that a TFTP server is running so that the new language files are

downloaded.

Emergency number for area and the address of server used by emergency number dialed.

Enter the STUN server IP address for STUN applications to use.

A Globally Routable User Agent URI is a URI that routes to a specific UA instance. When enabled, the phone obtains the GRUU parameter during registration. If the server supports GRUU, the phone will

include the GRUU parameter in its contact header.

If GRUU is disabled, or the server does not support GRUU, the phone assumes

current SIP release behavior

When enabled, phones obtain the firewall address from the specified proxy server. This enables or disables firewall NAT bypass

operation. When enabled, this feature lets the phone function behind a firewall that is

not SIP-aware.

WAN IP Address is for the external IP Address of the router.

When Hot Line Mode is On, all calls are automatically made to this address or number when

(57)

3- 31

Advanced Features continued…

Pressing the pound key ‘#’ at the end of a dialing sequence completes Dialing. For PBX-style plans, it may be necessary to dial a

preceding digit (9) to deliver dial tone to the phone. Enter the preceding digit here, if required. The Busy Lamp Field

(BLF) feature allows you to program a key that monitors whether or not another user is on a call. The BLF Key also acts as

a Speed Dial key to the monitored user’s number,

and as a Call Pickup key on behalf of the monitored

user.

The code used by the Server for Call Pickup

Provides a method to globally customize messages shown on Line 1 of an idle SIP Phone display by linking to an RSS feed URL

or an HTTP server feed or providing a Branding message (maximum 126 characters

including spaces).

A default URL link is supplied. To turn off RSS feed, clear this field.

RSS URL provides the full internet path for

the RSS Feed, Maximum buffer size of the RSS text buffer is 500 characters, remaining

characters are truncated.

Branding Text is identified by single quotes

around the branding text to be displayed. The branding text will be displayed on Line 1 when the phone is in Idle mode. If the text is

greater than the display are, then it will automatically scroll the message, Maximum

branding/note length is 119 characters. Enables/disables the HTML player feature. When

disabled, HTML Applications Master Filename is grayed out and is not available for user

modification.

Enable/disable the ability of the server to reset the phones using Notify messages.

(58)

Network Configuration

Required for cable access.

Optional. Maximum of 128 characters.

IPv4 = outgoing SIP requests use dotted format of IP address. Fqdn = outgoing SIP requests use “sip:[email protected]” format for

“contact” SIP header.

The server where updates to the firmware, languages and configuration files can be downloaded using the TFTP or

HTTP protocol.

Server used for date/time synchronization. Date/time programmed here will overwrite date/time user may have

programmed in Feature Configuration page.

Changes the phone tone plan.

The phone looks for configuration files on the TFTP or HTTP server when

booting up. The settings in the configuration files will overwrite any

manually entered settings. VLAN and QoS

Settings for the Phone

Point-to-Point Protocol over Ethernet. Enabled when using a

DSL network only

Computer-supported Telecommunications Applications (CSTA) Enable (set to On) for the 5330/5340 phones to allow

Companion Applications.

The CSTA Password is required for connections, enter an alpha-numeric password that you will enter to establish phone association when installing the PC Application software. Default

(59)

3- 33

Dial Plan

The phone tests digit strings by examining the top row first. If a match is not found in the first row, then the phone proceeds down the table until either a match is found or all the rules are exhausted. If a match is not found in the table, then the phone will send the digits exactly as they were entered to your SIP registration server for dialing.

Effective use of Dial Plan rules can eliminate the need for the user to terminate many common calls, and can simplify calls to special services such as discount long distance carriers.

When activated, this feature forces all dialed digits to use the inter-digit timer specified in the timer.

The Dial soft key or # will be disabled, and the entered digits will be dialed automatically after the

timer has expired.

The timer monitors the keypad for a pause in digit entry. When the timeout interval is exceeded, the digits are optionally modified, then sent to the SIP

registration server or alternate server.

Enter a partial or complete digit string (2 – 16 digits) for use as a template to test dialled digits. If the value of one or more digits is variable, then enter

the wildcard x in place of each variable digit. Use the square brackets [ ] to specify a set of digits, any one of which can match a dialled digit. For example, [123]

would be a positive match if the user dials “1”, ”2” or “3”, but would fail to match “4”.

The .T timer parameter (which must be placed at the end of a digit string) causes the phone to accept an arbitrary

number of digits from the user. Once the user has finished entering digits (signalled by no new digits for a period equal to the timer value), the digit string may have digit manipulation performed on it. The number is sent to the SIP registration server without requiring the user to

press the Dial soft key or #. Enter the number of digits expected

to follow the partial number Note that the Followed By field

must be set to 0 for the .T parameter to work.

Specify the IP address or domain name of another SIP

registration server (an alternate route) that calls meeting the criteria specified

will be automatically routed to. If left blank, the digits will be routed to the default SIP

registration server.

Can be used to specify suffix digits that are added to the digit string before the string is

sent to the SIP registration server for dialing. The digit

string can be: • a number • user name • SIP URL • SIP URL priority • IP address

(60)

Ethernet Configuration

Protocols

Auto setting allows the phone and PC to automatically negotiate the Ethernet speed

and duplex. If the PC does not support automatic negotiation, then manually select a

compatible setting.

Disabling HTTP access prevents future web-based sessions with the phone (i.e.

prevents access to the Web Configuration Tool). If you need access to the tool, then

enable HTTP through the phone's Settings menu interface. HTTPS allows for encrypted sessions.

Activating this protocol encrypts

media protocols.

Deactivating these protocols prevents communications with the phone via TFTP, Telnet or SNMP.

(61)

3- 35

Users and Passcodes

This is the passcode used by the phone installer in conjunction with the User ID during initial phone installation.

This is the UserID and Password to allow access to the Web Configuration

Tool. It is not the SIP Authentication user name.

The default passcode for admin is the phone type (eg 5340) and for a user it

(62)

Media Configuration

The Media Configuration page allows you to establish the audio parameters used by the phone when communicating with other devices.

Registration

G729A = 8:1 compression codec Three-way conference calls support only one

G729A stream.

Frame size in milliseconds used by G711 or G729 codecs. Increased in

10ms increments.

These fields specify the UDP port range used by the phone.

Used for DTMF tone generation (RFC2833). Outband used for RTP DTMF, default payload

type is 101.

The Registration page allows you to:

• Determine whether the phone is registered with a SIP server and, if so, for how long.

• View the current status of the registration process. For example, "retrying" or "renewing".

• Manually initiate a registration request.

The registration process is automatic. The Registration page is provided for troubleshooting purposes.

(63)

3- 37

Firmware Update

Displays version of current main and boot firmware loads.

A manual upgrade overrides all current firmware settings except for your Service Provider's TFTP server settings.

The main purpose of the boot load is to start the main load, and re-install the

main load.

Turn HTTP or TFTP firmware upgrade to On or Off, or set the upgrade to occur automatically. • Off - firmware upgrades cannot occur

• On - you are prompted for a firmware

upgrade if the firmware on the server differs from the firmware on the phone • Auto - automatic upgrades if the

firmware on server differs from firmware on the phone

Phone must be idle for an automatic upgrade to occur.

Select the timer type for automatic upgrades. • Absolute Time -

choose an actual time of day for the polling to take place

• Polling Interval -

choose an interval from 30 - 1440 minutes

If the download type is HTTP or TFTP, enter the server URL from which the new firmware will be

installed.

Directory paths and IP addresses are also supported.

(64)

Configuration Upload/Download

The Configuration Upload/Download page allows you to load, restore, or backup and save phone configuration

files by loading the files between the phone and the PC.

(65)

3- 39

Support

Help

If you select the Help hyperlink, you will be redirected to edocs.mitel.com and have access to the resources relating to the phone type.

(66)

;

Lab 2 – Configure a Mitel Phone in SIP mode

Configure a Mitel phone in SIP mode Connect the Mitel phone to a 3rd

Party SIP Server

Configure and Connect a Mitel 5224 phone in SIP Mode

1 Hold down the * and 7 keys and reboot the phone Keep the keys held down until you are prompted to release them

Leave the phone to boot up

If the keys are released too early, the phone remains in Minet mode

2 Using Internet Explorer, browse to the IP address of the phone

Use the following to authenticate: Username: admin

Password: 5224

The IP Address can be obtained from the System Configuration > IP Network Configuration > DHCP > DHCP Lease Viewer form on the 3300

The default password is the model of the phone.

3 Select the Quick Start option, in the left-hand pane under Admin Tools

4 Fill in the Quick Start form:

Note: x is your student id

User Details

User ID: 500x

User Display Name: Your Name

SIP authentication User Name: 500x

SIP Authentication Password: 500x

SIP Servers

SIP Proxy Server: IP Address from Instructor

Port: 5060

Scheme: UDP

SIP Registrar Server: IP Address from Instructor

Port: 5060

Scheme: UDP Click Apply

(67)

3- 41

5 The phone is now ready to use on a 3rd Party system

Testing the Mitel 5224 in SIP mode

6 Use the phone to call another student who has completed the previous exercise

Session Initiation Protocol Workshop

MITEL