Advanced SIP Features
| Site: | QSC |
| Course: | Q-SYS Quantum Level 1 Training (Online) |
| Book: | Advanced SIP Features |
| Printed by: | Guest user |
| Date: | Saturday, 23 November 2024, 4:25 AM |
Description
Transcript
00:08
Hi everyone, today our topic with be SIP telephony and some basic scenarios.
00:13
In some of our previous SIP telephony training we have discussed the basics of SIP
00:18
and how we configure the core to register with various types of systems.
00:22
In this lecture we are going to specifically focus on some of
00:25
the advanced features that the core provides for different situations.
00:29
As a quick refresh above we see a generic SIP network.
00:33
We have the core, a PC running a softphone, a SIP proxy like for example Cisco Call Manager,
00:40
and a connection out to the larger PSTN network.
00:43
In your implementation you may have more devices than this like network switches,
00:48
routers, and firewalls.
00:50
In this example we are registering to the SIP proxy and the proxy will respond with an
00:55
‘OK’ message once we are registered properly.
00:58
Now let’s dive into some things that can happen.
01:02
Let’s change things up a bit.
01:04
Let’s add a firewall between the core and the SIP proxy.
01:08
The SIP messaging still has to get through the firewall and to the proxy
01:12
but the firewall can introduce some problems.
01:15
On this diagram we’ve added some example IP addresses to the diagram.
01:20
The firewall has an inside private IP address that the rest of the world can’t reach
01:25
and also an outside public IP address.
01:28
The core will still be configured to register to the IP address of the SIP proxy,
01:33
in this case 10.2.1.1, but how does the firewall impact what happens next?
01:39
Moving away from the diagram for a second here we see a typical registration message from a core.
01:45
In a few places we see the SIP Proxy address of 10.2.1.1
01:50
and we also see a ‘Contact’ line that has the IP address of the core 192.168.0.1.
01:57
The firewall will pass this message to the proxy and the proxy will respond.
02:02
However, there’s going to be a problem.
02:03
We’ve told the proxy to respond to us at 192.168.0.1.
02:09
The SIP proxy on the other side of the firewall doesn’t know about that IP address.
02:14
Some firewalls will modify SIP messages so that the response can get back to us but some will not.
02:20
In that case we may never see a response
02:23
come back since it was sent to an address the proxy can’t reach.
02:27
How do we resolve this?
02:29
Let’s talk about our first feature of this lecture.
02:32
That’s STUN.
02:34
STUN stands for Session Traversal of
02:38
User Datagram Protocol [UDP] Through Network Address Translators [NATs]).
02:44
That’s a mouthful!
02:46
The simple version is that STUN allows a system to find out the outside address of the firewall
02:51
so that SIP messages and calls can get back to us.
02:55
Here we see the settings on the core for our softphones.
02:58
By default STUN is disabled. Let’s enable it.
03:04
Now we have STUN enabled and we see a new box to the right.
03:08
By default this box will be blank.
03:11
A STUN server is a server that will respond to a STUN message and send back
03:16
information to us containing the
03:18
outside IP address of the firewall so we can use it for future messages.
03:22
Here we have used a Google server that is commonly used.
03:26
It’s possible that another STUN server could be used as well.
03:30
Now if we went back and looked at a new Register messages with STUN enabled.
03:34
We’d see something different. Our contact address has changed to 10.1.1.1.
03:40
If we go back to our diagram we’ll note that this was the outside IP address of our firewall.
03:46
Now our proxy can send messages back to an
03:49
IP address it can reach and the firewall will forward them to us.
03:53
This doesn’t just impact registration. It also impacts calls as well.
03:58
Let’s take a look at a real wireshark capture.
04:01
Going all the way back to our earlier SIP trainings
04:04
we remember that RTP contains the audio stream.
04:08
In order for both sides to talk to each other the RTP stream should flow in both directions.
04:14
Here we can see that there’s only one RTP stream going out. We don’t see one coming back.
04:20
Why is that?
04:21
Think back to our SIP messages.
04:24
In the Register message we had a ‘Contact’ header.
04:27
In other SIP messages we recall that they contain SDP which has the parameters to set up our audio.
04:35
Here is a snippet of a SIP message showing the SDP info.
04:39
We have a number of fields here but the one we are interested in is the ‘c=‘ line.
04:44
This contains the IP address that the proxy is supposed to send audio back to,
04:48
in this case the core.
04:50
However, if we didn’t enable STUN that IP address is going to be the IP address of the core.
04:56
As we noted before the proxy can’t reach that address because of the firewall
05:00
so our audio is just getting lost in the network right now.
05:04
If we enable STUN that IP address will change to the outside address
05:08
of the firewall and we should get audio both directions again.
05:12
If you are behind a firewall and see issues with Registration
05:16
or Audio try enabling STUN and see what happens.
05:21
There’s another flag on the core you may have wondered about and that’s the Hold flag.
05:26
Some systems use an older method of putting a call on hold that doesn’t with the core.
05:31
The symptoms of this are that when a call is put on hold and then taken off hold
05:36
the audio never starts back up.
05:38
By default hold is enabled and that’s the normal way we do things.
05:42
This is what this looks like in a call flow.
05:45
We see that initially on our call we had RTP flowing in both directions
05:50
but after the call was put on hold we don’t start sending RTP again.
05:55
This is because when the call was put on hold we were told to send audio to
05:59
0.0.0.0 as an IP address
06:02
and then when the call is taken off hold we are given a new IP address.
06:06
Unfortunately this method is not supported by the core and we end up with one-way audio.
06:13
If we go back and change Hold to disabled we ignore this and our call will work normally again.
06:20
If you are having issues with one-way audio after a call is put on hold
06:24
this can be something to try.
06:27
Another feature you may have wondered about.
06:29
We have flag on the core called ‘Insecure Ciphers’. What does that mean?
06:34
It really only applies if we are using TLS and SRTP.
06:38
‘Ciphers’ are encryption methods.
06:40
It’s basically our method of encrypting our call.
06:44
If you think about secure websites it’s very similar.
06:47
When we use encryption both sides need to agree on what encryption method they are using.
06:52
As technology has advanced the need for more secure encryption has as well.
06:57
This is where this flag comes in.
06:59
The details don’t really matter here but
07:01
if you were to open a call in Wireshark or your sip.txt log
07:05
and open a SIP message with TLS and SRTP turned on you’d see a list of lines like this.
07:11
These are encryption methods that can be used. In our firmware we’ve turned off some of the
07:17
more insecure methods of encryption by default so that everything is encrypted more strongly.
07:22
However, some providers have not updated their own systems and still use older encryption.
07:28
Here we’ve enabled the insecure ciphers flag.
07:31
This will allow those older encryption methods to be used.
07:35
If you are having trouble with TLS and SRTP
07:38
it might be worth a try to enable this flag and see if it helps.
07:43
Next we have the ‘Domain Based Calling’ flag. What does this do?
07:48
Some SIP providers or proxies do additional verification
07:51
to see if you are allowed to Register or make calls by looking at the domain name.
07:55
By default the core doesn’t use the domain name for all fields in the SIP messaging.
08:00
Let’s enable this flag and see what happens.
08:03
First thing we should notice is that the Domain field which is normally optional is now required.
08:08
In order to use this flag we must have a domain entered.
08:12
Enter a domain and save the configuration. Now let’s look at what that did.
08:17
First up we have a Register message with the flag disabled.
08:21
We can see the domain present in the From and To line but not the top Register line.
08:27
Now with the flag enabled we see that the top line has changed to include the domain as well.
08:32
This lets our proxy know that this endpoint is from that domain.
08:37
Here we see a call without the flag enabled. Only the From line has the domain in it.
08:43
The applies to the invite as well. Here we see that the From,
08:48
To, and upper INVITE line all have the domain in them.
08:52
This lets the proxy know that our call is coming from a domain it recognizes.
08:56
This mostly applies to hosted SIP solutions but can be present in other situations as well.
09:02
That’s it for now on more advanced SIP features in the core.
09:06
These flags can help with more unusual situations that you may run into.