SUBSCRIBE messages

[Niek Vlessert]

Hello all,

I have a general question about subscribes messages. 

We use Yealink phones, quite a lot. We're running 16.12. We have issues; sometimes the load of all SipXproxy processes is >250% and they become unresponsive. Through iptables and research we learned this is probably caused by subscribe messages going between the servers and also from the phones. When I disable those using iptables the load goes down quickly. RLS is disabled.

When I open subscribe for a certain subnet the sipxproxy load on a server can spike again to 250% before returning to normal. Iptables shows me this can be caused by ~100 subscribe messages originating from that subnet.

When subscribe is open the general load of the proxy processes is roughly doubled and many more (little) spikes will happen. When I compare the amount of subscribe messages with the rest of the messages using iptables it's just rougly 10% of the SIP traffic.

We've already tried with a patch that stops the forwarding from subscribe messages. Without this patch the proxy processes spike more often. But that has nothing to do with the subscribe process itself.

So my question is basically; what is the reason subscribe uses this much horse power? And can I do something about it?

Since 16.12 I've seen some commit messages about subscribe things; UC-4637 and SIPX-726 to name a few, but I currently don't have enough insight to connect the dots myself.

Thanks in advance, regards,

Niek Vlessert

[Michael Picher]

So, phones generate subscribes, right? 

I don't know how many phones you have but they should subscribe for MWI, for BLF and BLA (SLA).

From the RFC (https://www.ietf.org/rfc/rfc3265.txt):

3.1.1. Subscription Duration

   SUBSCRIBE requests SHOULD contain an "Expires" header (defined in SIP
   [1]).  This expires value indicates the duration of the subscription.
   In order to keep subscriptions effective beyond the duration
   communicated in the "Expires" header, subscribers need to refresh
   subscriptions on a periodic basis using a new SUBSCRIBE message on
   the same dialog as defined in SIP [1].

   If no "Expires" header is present in a SUBSCRIBE request, the implied
   default is defined by the event package being used.

   200-class responses to SUBSCRIBE requests also MUST contain an
   "Expires" header.  The period of time in the response MAY be shorter
   but MUST NOT be longer than specified in the request.  The period of
   time in the response is the one which defines the duration of the
   subscription.

   An "expires" parameter on the "Contact" header has no semantics for
   SUBSCRIBE and is explicitly not equivalent to an "Expires" header in
   a SUBSCRIBE request or response.

   A natural consequence of this scheme is that a SUBSCRIBE with an
   "Expires" of 0 constitutes a request to unsubscribe from an event.

      In addition to being a request to unsubscribe, a SUBSCRIBE message
      with "Expires" of 0 also causes a fetch of state; see section
      3.3.6.

   Notifiers may also wish to cancel subscriptions to events; this is
   useful, for example, when the resource to which a subscription refers
   is no longer available.  Further details on this mechanism are
   discussed in section 3.2.2.

So the shorter you make your expires header the more traffic you'll generate. Phones should not have a setting of less than an hour and preferably much higher than that. 

So you can set values on the server if the phones don't allow for it:

You can set the MWI subscription max / min in System -> MWI

Check the SLA and RLS services for service controlled settings. The commercial version of the product uses a different service for BLF/BLA that can scale to about 5,000 users. It's much more efficient.

Also, in 18.04 we re-routed subscribes directly to BLF & BLA services instead of having proxy process them. This was inefficient and was actually causing some looping.

Additionally, in 18.04 there is new congestion management code that protects the proxy service from these traffic floods.

General warning with 18.04 is to pay close attention to the upgrade procedure highlighted in the release notes.

Thanks,

  Mike

Michael Picher, VP of Product Management
eZuce, Inc.

300 Brickstone Square

Suite 104

Andover, MA. 01810

O.978-296-1005 X2015 
M.207-458-1892
@mpicher <http://twitter.com/mpicher> 

linkedin
www.ezuce.com

Notice: This transmittal and/or attachments may be privileged or confidential. It is intended solely for the addressee(s) named above. Any dissemination or copying is strictly prohibited. If you received this transmittal in error, please notify us immediately by reply and immediately delete this message and all its attachments. Thank you.

--
You received this message because you are subscribed to the Google Groups "sipxcom-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-dev...@googlegroups.com.
To post to this group, send email to sipxc...@googlegroups.com.
Visit this group at https://groups.google.com/group/sipxcom-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-dev/5e3cf8ec-02fd-409c-b09b-a40431eb27a5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Niek Vlessert]

Hello Michael,

Thanks for your quick response, some interesting points in there, the rerouting should help us out and if not for some reason we have congestion management, very nice. :)

I'm not sure if the amount of subscribes is the issue, it might have something to do with the aggressive BLF subscription message sending from Yealink. If memory serves me right some firmwares send all their subscribes at once.

What are your thoughts about the subscription forwarding? It is used as a feature when doing a call pickup on a huntgroup, but on a regular user it's not very useful I would say? Maybe that's gone as well because the subscribes won't be processed by the proxy anymore?

I'll test 18.04 for sure.

Regards,

Niek

Op vrijdag 3 augustus 2018 17:40:04 UTC+2 schreef Michael Picher:

[Benedikt Machens]

Hi Niek,

there was a missing configuration check in 16.12. Yealinks will subscribe RLS, even when RLS is disabled or the user do not have a BLF. The Yealinks will flood the servers in this case with tons of messages.

In newer versions this is fixed.

Regards,

Benedikt

[Niek Vlessert]

Hello Benedikt,

I think in our Yealink provisioning the Yealink phones have RLS disabled.

Thanks,

Niek

Op maandag 6 augustus 2018 08:09:18 UTC+2 schreef Benedikt Machens: