Domain Specific SIP Profile

[PBXMePlz]

Hey all! I have this weird issue with phones that I think is network related.
The issue: sometimes a phone won't ring (not always the same phone), and a reboot fixes the problem. Sometimes BLFs on a specific phone won't function. Whole things screams of SIP ALG, but that's already been disabled.
I had another group suggest Compact SIP Headers due to a possible MTU issue, and although I'm pretty sure it's actually a double NAT issue (which I'm correcting), it did get me looking into Compact SIP Headers.
Looks like that's set on the Internal Profile:

Internal Sip Profile — FusionPBX Docs documentation

docs.fusionpbx.com

Also looks like you can maybe set these up as domain specific, but I was wondering if anyone has already done this and maybe had a screenshot they'd like to share. I'm multi-tenanted and would love to avoid causing problems.
Also, I'm assuming Compact SIP Headers decreases the size of each packet, why would this not be the default? What is the value of full SIP headers? Just curious as I'm assuming there's something basic I'm likely missing.

Thanks!

 

[Adrian Fretwell]

I don't think you can have a domain specific SIP Profile as such, but you could create another internal SIP Profile that listens on a different port and then configure the phones in one specific domain to register to that port.

Yes compact headers do reduce packet size, I always have them turned on, but only a few selected headers are shorthand, not all of them. Packet capture at the customers premises will tell you if you are exceeding MTU. I say at the customers premises because, the biggest SIP packets are often inbound NOTIFY messages for BLF subscriptions. If MTU is an issue that you cannot easily solve then consider switching to TCP.

Speaking of NOTIFY messages for BLF, the domain name is often repeated many times in a complex NOTIFY message, so keeping the FQDN short also helps to reduce SIP packet size. 1ip.uk is one of mine, they don't come much shorter than that!

Your issues do sound NAT related, you will need packet captures to diagnose it properly.

 

[PBXMePlz]

I don't think you can have a domain specific SIP Profile as such, but you could create another internal SIP Profile that listens on a different port and then configure the phones in one specific domain to register to that port.

Yes compact headers do reduce packet size, I always have them turned on, but only a few selected headers are shorthand, not all of them. Packet capture at the customers premises will tell you if you are exceeding MTU. I say at the customers premises because, the biggest SIP packets are often inbound NOTIFY messages for BLF subscriptions. If MTU is an issue that you cannot easily solve then consider switching to TCP.

Speaking of NOTIFY messages for BLF, the domain name is often repeated many times in a complex NOTIFY message, so keeping the FQDN short also helps to reduce SIP packet size. 1ip.uk is one of mine, they don't come much shorter than that!

Your issues do sound NAT related, you will need packet captures to diagnose it properly.

hmmmm...my domain name isn't too long, but now I want to shorten it, even a few characters repeated a few times adds up, especially in a packet.

I'm fairly certain the issue is that the ISP was handing a LAN IP to the modem. I've seen this before in Fixed Wireless networks, but it was a cable ISP, so there isn't a need for the modem to be receiving a LAN IP, which means there was likely double NAT issues. Hopefully we've sorted it out, now we wait and see.
Thanks for the info on the SIP profiles!

 

[Adrian Fretwell]

Hope you get it sorted.
Here is a bit of additional info on the subject of MTU and UDP fragmentation:

Below is a fragmented packet from a customer where we had BLF issues, I've changed the names, but they are all the same length as the original. Here we had an available MTU of 1500 bytes and the packet was 1516 bytes. You will see that
>
</dialog-info>
is missing from the end of the packet, you will also see how many times the domain cust001.myvoipsip.uk is repeated in the packet:

NOTIFY sip:2006@11.222.33.444:20934 SIP/2.0
Via: SIP/2.0/UDP 144.133.122.111:55060;rport;branch=z9hG4bKy60gv27v8ZvpD
Route: <sip:11.222.33.444:1030>;transport=udp
Max-Forwards: 70
From: <sip:2015@cust001.myvoipsip.uk:55060>;tag=YYhJLH5DQjjZ
To: "Sarah" <sip:2006@cust001.myvoipsip.uk:55060>;tag=2599100256
Call-ID: 0_4122517011@10.101.0.207
CSeq: 439000151 NOTIFY
Contact: <sip:2015@144.133.122.111:55060>
User-Agent: a2esPBX1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Event: dialog
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Subscription-State: active;expires=1132
Content-Type: application/dialog-info+xml
Content-Length: 617

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="123" state="full" entity="sip:2015@cust001.myvoipsip.uk">
<dialog id="e8073646-d0ca-417d-a276-070a7cc86a43" direction="recipient">
<state>early</state>
<local>
<identity display="2015">sip:2015@cust001.myvoipsip.uk</identity>
<target uri="sip:2015@cust001.myvoipsip.uk">
<param pname="+sip.rendering" pvalue="yes"/>
</target>
</local>
<remote>
<identity display="Tracey DDI Adrian Fretwell (Mobile)">sip:07123456789@cust001.myvoipsip.uk</identity>
<target uri="sip:**2015@cust001.myvoipsip.uk"/>
</remote>
</dialog

Compact Headers...
Below is a list of the headers that get shortened if you turn on compact headers:

a     Accept-Contact
b     Referred-By
c     Content-Type
e     Content-Encoding
f     From
i     Call-ID
k     Supported
l     Content-Length
m     Contact
o     Event
r     Refer-To
s     Subject
t     To
u     Allow-Events
v     Via

 

[PBXMePlz]

Hope you get it sorted.
Here is a bit of additional info on the subject of MTU and UDP fragmentation:

Below is a fragmented packet from a customer where we had BLF issues, I've changed the names, but they are all the same length as the original. Here we had an available MTU of 1500 bytes and the packet was 1516 bytes. You will see that
>
</dialog-info>
is missing from the end of the packet, you will also see how many times the domain cust001.myvoipsip.uk is repeated in the packet:

NOTIFY sip:2006@11.222.33.444:20934 SIP/2.0
Via: SIP/2.0/UDP 144.133.122.111:55060;rport;branch=z9hG4bKy60gv27v8ZvpD
Route: <sip:11.222.33.444:1030>;transport=udp
Max-Forwards: 70
From: <sip:2015@cust001.myvoipsip.uk:55060>;tag=YYhJLH5DQjjZ
To: "Sarah" <sip:2006@cust001.myvoipsip.uk:55060>;tag=2599100256
Call-ID: 0_4122517011@10.101.0.207
CSeq: 439000151 NOTIFY
Contact: <sip:2015@144.133.122.111:55060>
User-Agent: a2esPBX1
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Event: dialog
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Subscription-State: active;expires=1132
Content-Type: application/dialog-info+xml
Content-Length: 617

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="123" state="full" entity="sip:2015@cust001.myvoipsip.uk">
<dialog id="e8073646-d0ca-417d-a276-070a7cc86a43" direction="recipient">
<state>early</state>
<local>
<identity display="2015">sip:2015@cust001.myvoipsip.uk</identity>
<target uri="sip:2015@cust001.myvoipsip.uk">
<param pname="+sip.rendering" pvalue="yes"/>
</target>
</local>
<remote>
<identity display="Tracey DDI Adrian Fretwell (Mobile)">sip:07123456789@cust001.myvoipsip.uk</identity>
<target uri="sip:**2015@cust001.myvoipsip.uk"/>
</remote>
</dialog

Compact Headers...
Below is a list of the headers that get shortened if you turn on compact headers:

a     Accept-Contact
b     Referred-By
c     Content-Type
e     Content-Encoding
f     From
i     Call-ID
k     Supported
l     Content-Length
m     Contact
o     Event
r     Refer-To
s     Subject
t     To
u     Allow-Events
v     Via

So this was super helpful! Unfortunately my original thoughts turned out to be incorrect so now I'm thinking it must be an MTU issue.
When pinging and adjusting packet size, packets fragment after 1472, which seems a little small from the default 1500, but not super small. It's actually the same as another client, but they have less BLFs, which is likely related.

Do you know if there's any way to packet sniff on a Polycom VVX 410 so as to confirm this is the issue? I know how to do it on the Grandstream GRPs I'm using, but I don't know if it can be done on a Polycom VVX 410.

What are the concerns/downsides if any to turning on compact sip headers across the board?

Lastly I bought a much smaller domain, I wager I'm going to save 4 characters per instance the domain is used, I counted 7 uses of the domain in your example packet, so I should be saving some 28 characters per packet. I figure setting it up for their domain won't hurt, not sure if 28 characters is going to make the difference or not though.
Edit: updated numbers.

 

[Adrian Fretwell]

I don't think there are any issues to turning on compact headers, I have had then turned on for years, and never had an issue with them.

Your MTU of 1472 doesn't sound too bad, of course it depends on the overheads you have for encapsulation and framing on the circuit feeding your customer. You can generally work out what it should be by starting with the standard Ethernet 1500 and then subtracting the overhead for each encapsulation. For example, PPPoE has an encapsulation overhead of 8 bytes, coupled with the 20 bytes for the IP header this is 28 bytes; 1500-28=1472, spot on!

Many devices are capable of performing 'Path MTU Discovery' but this relies on ICMP responses for oversized packets and many poorly configured customer firewalls do not take account of this.

 

[DigitalDaz]

Just switch to TCP, its far easier than trying to squeeze back a few bytes.

I have found problems with compact headers in the past too.

Also, if you do squeeze back a few bytes, you then have the potential for Mr CustomerWithASuperLongName to come along, set that in his callerid name and you are back there again

We should all be looking to getting moved over to TLS/SRTP ASAP too before voip gets scrutinised too closely and all the customers realise anyone can potentially listen to their calls..

 

[PBXMePlz]

Just switch to TCP, its far easier than trying to squeeze back a few bytes.

I have found problems with compact headers in the past too.

Also, if you do squeeze back a few bytes, you then have the potential for Mr CustomerWithASuperLongName to come along, set that in his callerid name and you are back there again

We should all be looking to getting moved over to TLS/SRTP ASAP too before voip gets scrutinised too closely and all the customers realise anyone can potentially listen to their calls..

To be clear when you guys say switch to TCP, are you referring to the Device options by account, or it that only for registration? How might I switch a domain specific to TCP? I will look this up but it might be easiest to maintain the answer within this thread as well.
I ask largely because I default to TCP typically.

Also I agree about TLS/SRTP, it is on my shortlist which I had figured would help with a lot of this. I've seen it do nat busting much better.
That said, people have always been able to listen in on calls, the only difference I suppose is a physical wiretap?
And running TLS is great but you can't really dictate the other side. Doesn't mean we shouldn't do our part and be ready, just that the other side could be running old technology and then we're back in the same point. I assume VoIP will go through some of the changes like email has recently with SPF records and DMARC.

 

[Adrian Fretwell]

The SIP RFC states that a method to switch to TCP should be available if Packet size/MTU becomes a problem. But TCP should not be the norm, the SIP protocol was designed to use UDP to avoid the overheads associated with TCP.

When we say switch to TCP, just change your transport in the device config to TCP, by default FusionPBX supports both UDP and TCP.

 

[PBXMePlz]

The SIP RFC states that a method to switch to TCP should be available if Packet size/MTU becomes a problem. But TCP should not be the norm, the SIP protocol was designed to use UDP to avoid the overheads associated with TCP.

When we say switch to TCP, just change your transport in the device config to TCP, by default FusionPBX supports both UDP and TCP.

The transport under Devices is already TCP...so am I barking up the wrong tree here even?

Also this is unrelated to the topic at hand, but something maybe worth considering at some point would be like a new server setup list, consisting possibly of just a large index on different things that can and maybe are recommended to setup. I've noticed a couple times were things maybe should have been setup but there was nothing really prompting that of me.

Something Daz said reminded me of a change I made forever ago. I uncommented

<param name="startup-script" value="blf_subscribe.lua flow"/>

in the lua.conf.xml
Since the issues have been going on for a while, I don't know if this is the issue, I could see it being related if we're running into packet size issues on the Notify packet and it's a large callerID, and the transport is UDP, BUT if the transport is TCP like I've suggested, am I even looking at the right stuff with regards to MTU? Or are we back to possible NAT issues (which I'm not even sure what that would be at this point since SIP ALG is disabled, double NAT isn't in play anymore, and ports are correctly opened).

Addendum, but and I'm not sure I've mentioned this or not, of the like 5 different locations on this PBX, only this 1 is having the issue.