[Home]

Summary:ASTERISK-28669: chan_sip: Device states lost when sip reload
Reporter:cagdas kopuz (cagdas)Labels:
Date Opened:2019-12-23 09:14:07.000-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Channels/chan_sip/General
Versions:13.26.0 GIT 16.6.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-debuglog.txt
( 1) asterisk_logs.txt
( 2) realtime.txt
Description:Device states of agent lost when sip reload and after second call came same agent. After that, agent status forgot first call state and turn to second call's state. But first call still same states. By the way, queues' member states also changed. Log is attached.
Comments:By: Asterisk Team (asteriskteam) 2019-12-23 09:14:09.221-0600

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur.
By: Kevin Harwell (kharwell) 2019-12-23 11:50:32.844-0600

Please attach/post the relevant configuration data from _extensions.conf_, _sip.conf_, and _queues.conf_.

It would also be helpful if you could attach a debug log [1] (at least a 3 debug level) of the scenario.

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: cagdas kopuz (cagdas) 2019-12-24 00:05:12.170-0600

our peers and queues are realtime. Sip.conf, extensions.conf and realtime data attached.
By: Kevin Harwell (kharwell) 2019-12-24 13:14:24.024-0600

So far I have been unable to reproduce. What's the output of the following:
{noformat}
*CLI> core show version
{noformat}
Here's the basic steps I took. Please verify if this sounds correct:

1. Bob is a queue agent
2. Alice calls into queue, which rings Bob (state=ringing)
3. Bob answers (state=InUse)
4. Alice puts Bob on hold (appears to be what is happening from the log?)
5. Charlie calls into queue, which rings Bob (state=InUse&Ringing)
6. A "sip reload" is issued from the CLI
7. Bob is still on hold from Alice, and being rung by Charlie

On step #7 for me Bob's state is still equal to "InUse&Ringing", and has not changed after the reload.
By: Kevin Harwell (kharwell) 2019-12-24 13:16:12.408-0600

Also please enable regular (level=3), and SIP debugging [1] for the scenario and attach the log

[1] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks!
By: cagdas kopuz (cagdas) 2019-12-25 05:20:54.752-0600

I realized this situation occur only realtime SIP users. Second call and then reloading SIP, realtime peers destroyed. Log is attached.

A number (first caller): 321
B number (second caller): 103
Queue Agent: 205

Line:833-843
[Dec 25 14:05:39] DEBUG[22656]: chan_sip.c:5662 realtime_peer: -REALTIME- loading peer from database to memory. Name: 205. Peer objects: 0
[Dec 25 14:05:39] DEBUG[22656]: chan_sip.c:5237 sip_destroy_peer: Destroying SIP peer 205
[Dec 25 14:05:39] DEBUG[22656]: devicestate.c:474 do_state_change: Changing state for SIP/205 - state 1 (Not in use)
[Dec 25 14:05:39] DEBUG[22656]: chan_sip.c:30388 sip_devicestate: Checking device state for peer 205
[Dec 25 14:05:39] DEBUG[22685]: app_queue.c:2336 pending_members_remove: Removed SIP/205 from pending_members
[Dec 25 14:05:39] DEBUG[22685]: app_queue.c:2336 pending_members_remove: Removed SIP/205 from pending_members
[Dec 25 14:05:39] DEBUG[22757]: stasis.c:405 topic_dtor: Topic 'cache:17/endpoint:SIP/205': 0x7f0d0000ce18 destroyed
[Dec 25 14:05:39] DEBUG[22757]: stasis.c:405 topic_dtor: Topic 'endpoint:SIP/205': 0x7f0d0000d2f8 destroyed
[Dec 25 14:05:39] DEBUG[22656]: res_odbc.c:982 _ast_odbc_request_obj2: Reusing ODBC handle 0x7f0c800019e8 from class 'pbxconf1'
[Dec 25 14:05:39] DEBUG[22656]: res_config_odbc.c:117 custom_prepare: Skip: 0; SQL: SELECT * FROM sip_users WHERE name = ? AND host = ?
[Dec 25 14:05:39] DEBUG[22685]: app_queue.c:2484 device_state_cb: Device 'SIP/205' changed to state '1' (Not in use)
By: Joshua C. Colp (jcolp) 2020-01-02 05:56:56.810-0600

What "rt" options do you have enabled in sip.conf? (rtcachefriends for example)

As well there are some fundamental things with the way realtime works in chan_sip which can cause device state not to behave as you likely want.
By: cagdas kopuz (cagdas) 2020-01-02 06:13:51.257-0600

Realtime.txt file contains all of my sip.conf

rtcachefriends=yes
rtupdate=yes
By: Kevin Harwell (kharwell) 2020-01-03 16:25:37.962-0600

So I wasn't able to duplicate this exactly, but I am seeing similar type problems with device state, and _chan_sip_ with realtime. In my case after issuing the "sip reload" it still maintained the "Ring+Inuse" state. However, after terminating the second call (the one that was currently "ringing" the agent) the device state changed to "Unavailable" instead of back to "InUse".

After first call to agent (Note, only sip endpoints are configured in realtime. The queues I used the config file):
{noformat}
*CLI> core show hints

   -= Registered Asterisk Dial Plan Hints =-
101@default         : SIP/101               State:InUse           Presence:not_set         Watchers  0
_.@default          : ${TECH}/{$EXTEN}      State:Unavailable     Presence:                Watchers  0
----------------
- 2 hints registered

*CLI> queue show queue
queue has 0 calls (max unlimited) in 'leastrecent' strategy (1s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
  Members:
     101 (SIP/101) with penalty 1 (ringinuse enabled) (in call) (In use) has taken no calls yet
  No Callers
{noformat}
After second call:
{noformat}
*CLI> core show hints

   -= Registered Asterisk Dial Plan Hints =-
101@default         : SIP/101               State:InUse&Ringing   Presence:not_set         Watchers  0
_.@default          : ${TECH}/{$EXTEN}      State:Unavailable     Presence:                Watchers  0
----------------
- 2 hints registered

*CLI> queue show queue
queue has 1 calls (max unlimited) in 'leastrecent' strategy (1s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
  Members:
     101 (SIP/101) with penalty 1 (ringinuse enabled) (in call) (Ring+Inuse) has taken no calls yet
  Callers:
     1. SIP/103-00000008 (wait: 0:10, prio: 0)
{noformat}
After sip reload:
{noformat}
*CLI> sip reload
*CLI>
*CLI> core show hints

   -= Registered Asterisk Dial Plan Hints =-
101@default         : SIP/101               State:InUse&Ringing   Presence:not_set         Watchers  0
_.@default          : ${TECH}/{$EXTEN}      State:Unavailable     Presence:                Watchers  0
----------------
- 2 hints registered
*CLI> queue show queue
queue has 1 calls (max unlimited) in 'leastrecent' strategy (1s holdtime, 0s talktime), W:0, C:0, A:0, SL:0.0% within 0s
  Members:
     101 (SIP/101) with penalty 1 (ringinuse enabled) (in call) (Ring+Inuse) has taken no calls yet
  Callers:
     1. SIP/103-00000008 (wait: 0:10, prio: 0)

*CLI> core show hints

   -= Registered Asterisk Dial Plan Hints =-
101@default         : SIP/101               State:InUse&Ringing   Presence:not_set         Watchers  0
_.@default          : ${TECH}/{$EXTEN}      State:Unavailable     Presence:                Watchers  0
----------------
- 2 hints registered
{noformat}
After second call termination:
{noformat}
*CLI> core show hints

   -= Registered Asterisk Dial Plan Hints =-
101@default         : SIP/101               State:Unavailable     Presence:not_set         Watchers  0
_.@default          : ${TECH}/{$EXTEN}      State:Unavailable     Presence:                Watchers  0
----------------
- 2 hints registered
*CLI> Really destroying SIP dialog '19ca05ea71804746086d55eb3cc2ec6d@10.24.20.47:5060' Method: INVITE
core squeue show queue
queue has 0 calls (max unlimited) in 'leastrecent' strategy (1s holdtime, 0s talktime), W:0, C:0, A:1, SL:0.0% within 0s
  Members:
     101 (SIP/101) with penalty 1 (ringinuse enabled) (in call) (Unavailable) has taken no calls yet
  No Callers
{noformat}
So issuing the reload, and then hanging up caused an unwanted device state for me.
By: Kevin Harwell (kharwell) 2020-01-03 16:31:32.513-0600

I'm going to go ahead and open this issue up, but as [~jcolp] said:
{quote}
... there are some fundamental things with the way realtime works in chan_sip which can cause device state not to behave as you likely want.
{quote}
It could be that if anyone eventually looks into this that they find that's just the way _chan_sip_ has always worked, and attempting to alter the behavior would not be feasible.

*Please do note though*

The chan_sip channel driver is in 'extended' support status and is supported only by community members.  Support times will reflect that. Your patience is appreciated as a community developer may work the issue when time and resources become available.

Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1]

If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way.

[1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
[2]: http://www.asterisk.org/community/discuss
[3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties
By: Joshua Elson (joshelson) 2020-01-05 12:51:31.784-0600

Having had a great deal of experience with chan_sip and realtime, you more or less never should operationally use a sip reload with realtime. No matter the rt* settings, you will end up causing all peers to be removed from memory until another action causes them to be looked up again from realtime and/or the device re-registers, but as this bug points out, existing device state is lost. In my view, this behavior is by design.

Practically speaking though, you should never really need a sip reload in the course of “normal” operations. If you need to update cached peer information, a sip prune XXX will get you what you want in a far more surgical way. Other lower level operations rolled up in the reload command can be done in other ways or scheduled when peers are not in use.