[Home]

Summary:ASTERISK-23294: SIPqualifypeer (over AMI) does not update status when peer is UNREACHABLE
Reporter:MS (ims77)Labels:
Date Opened:2014-02-13 05:47:45.000-0600Date Closed:2014-02-13 08:31:07.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:11.7.0 Frequency of
Occurrence
Related
Issues:
Environment:Ubuntu 12.04Attachments:
Description:I'm using a manager (wrote in c) to execute some specific actions using AMI.

1- Register a peer to Asterisk => if you execute "sip show peers" you can see the ip of the host and the status is OK
2- Kill the peer => if you have a high value for qualifyfreq, the informations are still available (ip and status)
3- Send the action SIPqualifypeer from AMI => you will see in the console the message : __sip_xmit: sip_xmit of 0xb6d0c798 (len 1007) to 192.168.48.206:49261 returned -2: Resource temporarily unavailable
You don't have the message Peer 'mypeer' is now UNREACHABLE!

When you read the c code of chan_sip you can see that the function sip_poke_peer() call xmitres = transmit_invite(p, SIP_OPTIONS, 0, 2, NULL);
This function calls send_request() which calls
res = (reliable) ? __sip_reliable_xmit(p, seqno, 0, req->data, (reliable == XMIT_CRITICAL), req->method) : __sip_xmit(p, req->data);

In my case, the value returned by __sip_reliable_xmit is not XMIT_ERROR but AST_FAILURE then in the function sip_poke_peer() the function sip_poke_noanswer() is not called and finaly the status is not updated.

I think there is a problem. I'm new to Asterisk so I can't make the patch but I think the return should test the both cases or just not return AST_FAILURE.
Comments:By: Matt Jordan (mjordan) 2014-02-13 08:31:00.761-0600

It won't call {{__sip_reliable_xmit}}. It will call {{__sip_xmit}}, which only returns {{XMIT_ERROR}} on error. This is what {{sip_poke_peer}} checks for:

{noformat}
if (xmitres == XMIT_ERROR) {
/* Immediately unreachable, network problems */
sip_poke_noanswer(sip_ref_peer(peer, "add ref for peerexpire (fake, for sip_poke_noanswer to remove)"));
} else if (!force) {
{noformat}

As it is, there may be a bug here, but it's rather hard to tell from your issue description. Without an actual patch to look at, the issue tracker is usually not the best place to have discussions of code behaviour. I would recommend doing one of the following:
# Continue this discussion on the asterisk-dev mailing list, which is a better forum for discussions of this type.
# Attach a patch that modifies the behaviour of Asterisk to fix what you believe you have found.

I'm going to close this out as "Not a Bug". If you have a patch, please contact a bug marshal in #asterisk-bugs and this issue can be re-opened.