Basic SIP Telephony
Transcript
00:08
Hi everyone,
00:09
today our topic with be basic SIP telephony integration with CUCM.
00:14
SIP integration can be one of the most challenging aspects of Q-SYS.
00:18
In the Quantum ‘Introduction to SIP Telephony’ topic,
00:21
we discussed the underlying technology of SIP telephony,
00:24
but in this section we’ll look at SIP telephony from a more practical angle.
00:28
In this lecture we’ll integrate the Q-SYS softphone with a real SIP
00:32
proxy to get a deeper understanding
00:34
of the typical setup of the proxy itself
00:36
and what we need to know about that setup to be successful in registering and making calls.
00:42
In this particular case,
00:43
we’ll explore the methods for integrating the Q-SYS softphone
00:46
to Cisco Unified Communications Manager, or CUCM.
00:50
We’ll test this integration by making test calls to and from a
00:53
Q-SYS system from a softphone application running on a PC.
00:57
Keep in mind the topology here is greatly simplified
01:00
from an actual enterprise VoIP deployment,
01:02
but the basic concepts shown here should apply to any running CUCM implementation.
01:08
In this diagram we have a couple of basic devices.
01:11
A server running Cisco Call Manager (CUCM), a core, a laptop running a softphone,
01:18
and a network ethernet switch connecting it all together.
01:21
In your network you may have additional devices like routers and firewalls not pictured here.
01:26
The steps will be as follows:
01:29
The first step for most SIP telephony endpoints is to register with the SIP proxy.
01:35
In this case, CUCM checks the credentials of each endpoint and responds accordingly.
01:40
The endpoints can make calls when and only when they’re registered with the call manager.
01:46
We’ll discover that different methods are required to interface Q-SYS to CUCM
01:50
depending on the number of Q-SYS softphones required in your project.
01:55
In this workshop we are going to focus on single softphone registration.
01:59
In future workshops we’ll address multiple softphones and SIP trunking with CUCM.
02:04
The scenarios described here are specific to CUCM.
02:07
Other systems have different ways of handling these implementations
02:11
and will be discussed in other trainings.
02:14
The steps to configure an account in CUCM for the Q-SYS Softphone are as follows:
02:19
First we create the Security profile that will be used for the Softphone.
02:24
Next we create the End User profile that includes the
02:27
credentials the softphone will use to register.
02:30
Finally we create the phone definition which
02:32
consists of a Device and an associated Directory Number.
02:36
The Directory Number is the phone number used for the softphone. Let’s look at each step in detal.
02:42
When one and only one softphone is required in a given Q-SYS design,
02:47
it is typically registered as a ‘Third-party SIP Device (Basic).
02:51
Each SIP endpoint in CUCM requires licensing credits, and this is the least expensive option.
02:58
The very first part of defining the softphone in CUCM is to create a ‘Phone Security Profile’.
03:05
The items to note here pertinent to the Q-SYS configuration
03:08
are the Name, the Transport Type, Digest Authentication, and SIP Phone Port.
03:15
We’ll go over these one by one.
03:18
First the security profile needs a name.
03:21
This name can be whatever you want but it will be used later so remember the name you used.
03:27
The transport type determines whether Q-SYS should use the UDP
03:31
or TCP network transport for SIP messages to and from CUCM.
03:36
Remember this determines the behavior of the signaling plane, the call control messages,
03:41
but not the audio transport used to send and receive audio.
03:46
Digest Authentication is the name of the method the Q-SYS softphone uses
03:50
to validate its username and password with CUCM.
03:53
This is the only authentication method supported by Q-SYS.
03:58
The SIP Phone Port sets the UDP/TCP port number used to interface to the Softphone.
04:04
Port 5060 is the standard port number, but it can be manually changed by the system administrator.
04:10
Our next step is to configure an End User.
04:13
This screen allows us to configure a User ID and Password for authentication.
04:18
The ‘User ID’ in the end user setup corresponds
04:21
to the authentication username in the Q-SYS softphone setup.
04:25
The tricky part is the password immediately below this user ID is NOT the authentication password.
04:32
It’s also NOT the PIN below that.
04:35
The ‘Last Name’ field doesn’t really do anything but it needs to be filled
04:39
in so we can just use ‘Q-SYS’ as the last name.
04:42
Instead, the authentication password is set in the ‘Digest Credentials’ field.
04:48
That may not seem incredibly intuitive, but remember that we enabled “Digest Authentication,”
04:54
so it makes sense that the softphone is using digest authentication to register.
04:59
The final step is to configure a phone device of the correct type tied to that user account.
05:04
We see here the device is set up as a basic third-party SIP device.
05:09
There are a large number of settings on the Device screen so if following along on your own CUCM
05:15
scroll down to see the settings above.
05:17
Here we see the device type again along with the user ID in the ‘Owner’ field.
05:23
The ‘Owner User ID’ is the same as you configured earlier in the End User config
05:27
and also corresponds to the Authentication Username on the core which we’ll see later.
05:33
There is also an entry for ‘Device Pool’ here which is set to Default.
05:37
This is a more advanced setting but it controls which CUCM servers the device can register to
05:42
and also access to things like media resources.
05:45
Check with your CUCM administrator
05:47
regarding appropriate Device Pool settings for your implementation.
05:51
In the Protocol Specific Information at the bottom of this page,
05:55
we assign the device security profile we created before.
05:59
The SIP Profile controls all of the basic SIP parameters for this phone.
06:04
Most of the time those do not need to be modified unless requested by a network administrator.
06:08
The ‘Standard SIP Profile’ should work with our softphone but if needed you can copy the standard
06:14
profile and create a separate ‘Q-SYS SIP Profile’
06:17
and assign it instead. We also specify the digest user we created for this account.
06:23
We also have a field here for ‘Media Termination Point Required’.
06:28
This is for scenarios where you might be using G.729 to interface to CUCM
06:33
but CUCM is using G.711 to talk to the wider telephone network.
06:38
This is called transcoding and if calls aren’t working it’s something to check.
06:42
This might even be required if different DTMF methods are being used in the network.
06:47
When you are done with the configuration you should click ‘Save’ and ‘Apply Config’.
06:52
Otherwise this configuration could be lost and is not active yet.
06:56
The next step is to associate a directory number with a device.
07:00
From the top of the Device screen click on ‘Add a new DN’ on the upper left.
07:06
The directory number is the first field and represents the phone extension.
07:10
This will normally be a 4 digit number but depends on your configuration.
07:15
In the ‘Associated Devices’ section you would use the MAC address of
07:19
the device from our previous step. CUCM sometimes fills this in automatically.
07:24
Now if you go back to the device you will see the directory number associated with the device.
07:30
Now that the account is set up in CUCM, we turn our attention to the setup in Q-SYS Core Manager.
07:36
First and foremost we must confirm the core network configuration…
07:40
we want to make sure the correct Q-SYS NIC is connected to the VoIP network
07:44
and the correct IP address options are chosen.
07:47
We spent a substantial amount of time on this in the networking sections of Quantum training,
07:51
so we’ll trust that we know how to accomplish this.
07:54
The next step is to confirm the shared settings for all softphones.
07:58
In this setup we will use LAN A as the VoIP interface.
08:02
The SIP signaling port is set to 5060, which again is the default.
08:07
We saw this in the CUCM setup.
08:09
This is the SIP signaling port for the core and is used for incoming calls to the core.
08:14
The port used for outgoing calls to talk to CUCM is set later.
08:20
SIP logging here is enabled, which will be a useful troubleshooting
08:23
tool if we run into problems. By default this is disabled.
08:28
The rest of the shared settings we covered in Quantum training before
08:31
but a quick refresh of the typical settings is shown.
08:34
SRTP is normally disabled.
08:36
DTMF INFO is disabled as well.
08:39
CUCM does not typically use these methods.
08:42
The DTMF type is also fine for this application. STUN is also disabled.
08:47
This applies mostly to hosted SIP solutions when
08:50
the core is behind a firewall which is not the case here.
08:53
Now let’s look at the individual Softphone settings.
08:57
The ‘proxy’ field specifies the address of the CUCM server.
09:01
In some scenarios a network can have more than one CUCM server.
09:06
In redundant proxy applications, there’s a ‘Backup Proxy’ field to point to the secondary unit.
09:12
By default the proxy is using port 5060 but if you
09:15
need a different port you can append it to the proxy ip with a ‘:’.
09:21
In this case we do want to register with the proxy.
09:25
Most systems require this level of security, including this one.
09:29
The transport setting selects the method of SIP communication required for CUCM.
09:35
In this case, you’ll remember that CUCM was set to use UDP.
09:39
This could also be TCP, depending on the configuration.
09:43
We now move to the individual account settings we set in CUCM.
09:48
The ‘Username’ field represents the subscriber number assigned in CUCM.
09:53
These two fields must match or we will not be able to register.
09:58
The Authentication ID represents the digest username in the end user account setup.
10:04
Remember, the password represents the digest credentials in the end user account setup,
10:09
not the password or PIN fields.
10:12
This is very important to remember.
10:14
….And voila! Provided all those items are correct, the softphone is registered!
10:19
Success! Wait! What? CUCM tells us in the softphone status we have a fault.
10:26
This leads us to an important piece of trivia about CUCM.
10:31
The Authentication username is case sensitive. Note the cases shown do not match.
10:38
Correcting this will finally result in a successful registration!
10:43
We covered the details of how registration occurs during Quantum training
10:47
but as a refresher here is an example of a successful registration
10:51
that you would see in Wireshark if you grabbed a packet capture from the core.
10:56
Once we correct this, the ‘OK’ status indicates the softphone is registered
11:00
and ready to make calls.
11:02
We see green in the softphone status block and know that’s good.
11:06
Now let’s try to make a test call.
11:09
Now we can dial our computer softphone at extension 2001.
11:14
The softphone is answered and we see the softphone in the connected state.
11:18
We hang up and the call disconnects as expected. The test call was a success!
11:23
Let’s look at the exchange between the different peers who participated in the call.
11:29
Sometimes everything looks correct with our configuration in the core
11:32
and CUCM and things still don’t work!
11:35
There are a few other common things to recheck.
11:38
If you go back to CUCM make sure that under the Device configuration
11:43
that we didn’t miss configuring a digest user.
11:46
It’s down pretty far in the configuration so sometimes it’s easy to miss.
11:50
Also go back and check again that ‘Enable Digest Authentication’ is checked.
11:56
Also easy to forget and nothing will work if the box isn’t checked.
12:00
When we look at this interaction, it’s easy to see the role of the proxy server in call setup.
12:06
We see an interaction between Q-SYS and CUCM.
12:10
Then we also see an interaction between CUCM and the peer we’re calling.
12:15
The key takeaway here is that the proxy server acts as the traffic-cop between the peers.
12:20
The direct interaction between them comes only after the session is negotiated by CUCM.
12:27
Let’s analyze the traffic flow from end to end to understand the process:
12:32
At the very first we see the Q-SYS softphone
12:35
INVITE the destination to a call by contacting CUCM.
12:39
CUCM then issues a challenge to authenticate
12:42
before passing along the INVITE to the destination.
12:45
The Q-SYS softphone issues a new INVITE message with the encrypted password in response.
12:51
This is where we’ll start charting the exchange between all the devices involved.
12:55
The new INVITE message is received by CUCM.
12:59
It includes the Session Description Protocol, or SDP,
13:03
information so that CUCM knows what audio formats (codecs) it supports.
13:08
SDP also contains information about which IP addresses will be sending and receiving RTP
13:14
and which network ports to use for RTP.
13:17
If SDP is included in the INVITE this is called the early offer method.
13:22
CUCM in turn INVITEs the far end, extension 2001.
13:27
Since 2001 is another phone registered with CUCM,
13:31
it knows how to reach that peer where the Q-SYS Softphone would not.
13:35
CUCM replies to Q-SYS to say TRYING… which means ’I’m working on that’
13:41
The destination in turn replies with ‘I’m working on it’, and then with RINGING,
13:46
to let CUCM know that it’s prompted the user of that phone to answer.
13:51
CUCM then passes that along so that the Q-SYS softphone
13:54
can notify the user that the far end is ringing.
13:57
This notification is also what triggers the caller to hear ringing.
14:02
The destination responds with an OK…this includes the SDP
14:06
information about which codec the call will be using for that leg of the call.
14:10
The leg between CUCM and the destination
14:13
may not use the same codec that is used between the Q-SYS Softphone and CUCM.
14:18
This is called transcoding.
14:20
CUCM compares the codec list to our initial offer in the INVITE.
14:25
It sends a message with the highest-priority match for both peers.
14:30
Q-SYS then Acknowledges that codec selection and SDP information.
14:34
Amongst other information included in the Session Description Protocol is the contact information
14:39
(IP addresses, port numbers, etc for the other end of the call.
14:43
This now allows the peers to exchange audio directly with each other.
14:48
The peers start to exchange audio and begin the call in earnest.
14:53
This isn’t included in the flow diagram, as the capture was taken on the machine hosting CUCM.
14:58
These packets would only be seen on a capture from Q-SYS or the destination.
15:03
Note that any in-call DTMF would be handled as RTP EVENT type messages directly between peers.
15:11
They would show up in the RTP flow as well.
15:15
After a few seconds in call, the Q-SYS softphone ends the call. We see this as a ‘BYE’ message.
15:21
Note this goes back to CUCM rather than directly to the far end of the call.
15:27
CUCM then forwards the BYE message to the far end. If the other side hangs up,
15:32
the BYE messages would flow in the other direction.
15:36
The far end responds with an OK that is also passed from CUCM to the Q-SYS softphone.
15:43
Now we’ve seen the SIP account created in CUCM and Q-SYS,
15:48
and we’ve seen how the data from the CUCM account setup fits in the Softphone configuration.
15:53
We’ve conducted a simple analysis of the registration process
15:56
and the process of making a call.
15:58
Next let’s take a look at some other issues that can occur.
16:02
Other status messages on your softphone may appear.
16:06
Two common ones are ‘Registration Timeout’ and ‘Service Unavailable’.
16:11
‘Registration Timeout’ means that the core did not get a response from CUCM.
16:16
This might be a network issue or the wrong IP address.
16:20
‘Service Unavailable’ means that registration couldn’t happen.
16:23
This might mean that digest authentication is not turned
16:26
on or that CUCM is not accepting registrations for another reason.
16:30
A codec mismatch means that both sides could not agree on a codec to use.
16:36
Let’s go through these one by one and learn how to identify and fix them.
16:40
First let’s learn how to turn on logging and find the logs on the core.
16:45
In core manager under the Softphone tab click on ‘Edit’ and then enable logging. Then click ‘Save’.
16:53
This will turn on logging so that we can see what’s happening on the core in real time.
16:58
We can see messages between the core and
17:00
the proxy including registration attempts and calls that we place.
17:04
Then open a browser window and for the URL use the IP address of the core followed by /sip.txt.
17:14
An example would be in the format http://192.168.0.23/sip.txt.
17:23
This will open the SIP logging page where we can see messages between the proxy and the core.
17:28
This log can also be used to view SIP calls as well when they are placed.
17:32
The newest messages are at the very bottom.
17:32
The log does not automatically slow so refresh to see new messages.
17:37
Now that we’ve got logging turned on let’s look at some things that you might see.
17:42
Let’s recall that in the core we had to specify a proxy IP address.
17:46
However, sometimes we see a ‘Registration Failed
17:49
(Service Unavailable)’ or ‘Request Timeout’ in the softphone status
17:53
after we complete our configuration.
17:55
There could be a couple of reasons.
17:57
One reason might be is that the proxy is not reachable on the LAN interface we picked earlier.
18:02
If we enable logging on the softphone and look at our sip.txt file we may see the message above.
18:08
We see where we sent a message to the IP address of the proxy and got a ‘Request
18:13
Timeout’ because we got no response.
18:16
If this happens check with your network administrator to make sure the core is using
18:20
the correct LAN interface and that you have the correct IP address for CUCM.
18:25
Let’s go back and look at another possible issue.
18:28
The Username in the softphone refers to an extension configured on the call manager.
18:33
They must match or the softphone will not register.
18:36
If ‘1001’ is not a valid extension on the call manager
18:40
we will see a ‘Not Found’ error when the softphone tries to register.
18:45
Here we see that message in the softphone block as our status.
18:50
If we go back to CUCM, in this examples we see that we have a Directory Number of ‘2010’
18:56
which does not match what we configured on the core manager.
18:59
If we correct them so both sides match then we should be able to register.
19:05
If we place a call we may see this message in the softphone block.
19:09
What does this mean? Let’s take a look at the sip.txt log and see what it shows.
19:15
The sip.txt log shows us this.
19:17
This means that we tried to set up a call using a codec that CUCM doesn’t have enabled.
19:23
Go back to core manager
19:25
and try enabling all codecs if they aren’t already and try the call again.
19:30
Also make sure that SRTP isn’t accidentally checked while UDP is being used.
19:36
SRTP should only be checked if TLS is also checked.
19:41
That’s it for basic SIP registration with CUCM.
19:45
In future trainings we will discuss Advanced Registration on CUCM with multiple softphones
19:50
and SIP trunking for CUCM.