Debugging BLF Problems

To debug BLF we need the following traces.

They are for the time period where the monitored phone (phone A) receives a call from another phone (phone B), but the subscribing phone (phone C)'s BLF light is not set correctly:

1. A ngrep trace on the Kamailio/OpenSIPS server showing all traffic to and from phones A and C. It might be easiest to take a PCAP of all network traffic passing through the server using: ngrep -d any -O /tmp/ticket-XXXX.pcap > /dev/null If you get an error about privileges, add -R to the command like this: ngrep -d any -R -O /tmp/ticket-XXXX.pcap > /dev/null
2. An Asterisk SIP and AGI trace of the call from phone B to phone A. You can take this using the Reports -> Traces menu at the system level in Enswitch.
3. A Mysql general log showing all SQL queries. See: https://dev.mysql.com/doc/refman/5.7/en/query-log.html

Please also let us know:

1. The number of phone A (monitored phone).
2. The number of phone B (calling phone).
3. The number of phone C (subscribing phone).
4. The exact start time of the call which triggered the BLF activity.
5. A description of what exactly was not correct. For example: "When phone A started to ring, the BLF light on phone C did not light up, and still did not light when phone A picked up the call".

It helps a lot fix the issue if the call uses the simplest possible scenario, so for example:

1. Have just one phone (C) with a BLF subscription for the monitored phone A, and have no BLF subscriptions on phone A or B. This way a NOTIFY for phone C from phone A can't be confused with a NOTIFY for phone A from phone C.
2. Use a direct phone-to-phone call, not hunt groups or queues (unless the problem only happens using hunt groups or queues).
3. Take the traces when the system is as quiet as possible, for example late in the evening.
4. Include just one call which reproduces the problem in the traces. Usually only one example is necessary, but if taking multiple calls put them in separate trace files.