[Home]

Summary:ASTERISK-17865: app_queue INVITE-ing unregistred SIP
Reporter:Cristian Dimache (cristiandimache)Labels:
Date Opened:2011-05-16 07:53:49Date Closed:2011-07-26 14:59:25
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Applications/app_queue
Versions:1.8.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 2011-05-18-messages_-_trim.txt
Description:app_queue (I think it's app_queue) is sending INVITE to a unregistred SIP peer, and then chan_sip logs "Retransmission timeout reached on transmission"

****** ADDITIONAL INFORMATION ******

$ sudo asterisk -rx 'sip show peer 298'
Peer 298 not found.

Relevant entries from log:

Max-Forwards: 70
From: "0000" <sip:0000@192.168.0.3>;tag=as7467fe38
To: <sip:298@192.168.0.148:5060;ob>
Contact: <sip:0000@192.168.0.3:5060>
Call-ID: 249498f00b4201e97d85680151ab5e19@192.168.0.3:5060
CSeq: 102 INVITE
User-Agent: voip1
Date: Mon, 16 May 2011 12:44:16 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH

[May 16 15:44:48] WARNING[23486] chan_sip.c: Retransmission timeout reached on transmission 249498f00b4201e97d85680151ab5e19@192.168.0.3:5060 for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 32000ms with no response
[May 16 15:44:48] VERBOSE[23486] chan_sip.c: Really destroying SIP dialog '249498f00b4201e97d85680151ab5e19@192.168.0.3:5060' Method: INVITE
Comments:By: David Woolley (davidw) 2011-05-16 08:36:04

If you don't have host=dynamic, the peer doesn't need to be registered for outbound calls to be made.  If you do have host=dynamic, the peer must be registered in order for Asterisk to know the address.

Also note that app_queue has no knowledge about SIP.

To avoid an unconnected peer being selected, you need to use the qualify option, in sip.conf.

I believe this is a configuration problem, not a bug.


By: Cristian Dimache (cristiandimache) 2011-05-16 09:17:25

I do have host=dynamic and qualify=no.

In other words, the problem should be "chan_sip tries to INVITE a non-registered peer"?
The reason that I added "app_queue" in the mix is that it first appeared that this is valid only for queue calls... testing some more it appears that the problem is the same for a direct call to the unregistered SIP peer.

I will try with qualify=yes, but I don't think we should require Qualify to see that a peer is unregistred and purged from realtime cache peers.

Check the timestamps:
[May 16 14:32:55] VERBOSE[23486] chan_sip.c:     -- Unregistered SIP '298'
[May 16 15:44:48] WARNING[23486] chan_sip.c: Retransmission timeout reached on transmission 249498f00b4201e97d85680151ab5e19@192.168.0.3:5060 for seqno 102 (Critical Request) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions [^]
Packet timed out after 32000ms with no response

So chan_sip tries an INVITE after the "Unregistered" message is logged.
By: Cristian Dimache (cristiandimache) 2011-05-17 01:49:19

With qualify=on INVITEs are sent to SIP peers in UNKNOWN state.
By: David Woolley (davidw) 2011-05-17 05:53:32

You are looking at this at the wrong stage.  The question is why is the address not being cleared on the unregister, for which you need to provide the sip debug for the unregister and sip show peers before and after, and why the state is not being set to unavailable when the qualify fails, for which you require similar information for the OPTIONS challenge.
By: Leif Madsen (lmadsen) 2011-05-17 07:22:41

Your configuration files would also be appropriate. I think davidw is right in that this is a configuration issue, and not a bug.
By: Cristian Dimache (cristiandimache) 2011-05-17 23:59:22

The file 2011-05-18-messages - trim.txt contains a SIP debug enabled for this peer.
The SIP peer was unregistered at 07:36:28, then at 07:36:39 i called the unregistred SIP extension and it kept trying.

This is the only relevant (i think) info in the sip.conf

; Cache RT Friends
rtcachefriends=yes
rtautoclear=yes

Peers are in realtime loaded in extconfig.conf with

sipusers => pgsql,PRODUCTION,t_voip_sipbuddies
sippeers => pgsql,PRODUCTION,t_voip_sipbuddies
By: David Woolley (davidw) 2011-05-18 05:06:37

You didn't provide sip show peers output.

If there is a problem it is that the Contact information is being stored rather than cleared on getting REGISTER with expires=0.

The trace doesn't show any new connection attempts after the qualify fails.
By: Cristian Dimache (cristiandimache) 2011-05-18 05:24:51

After the qualify fails the behaviour is OK - no more retries on the unreachable peer - so only a one-time problem with qualify=yes.
But the bigger problem I guess is at qualify=no, where the Unregister does not clear the SIP peer.
By: Leif Madsen (lmadsen) 2011-05-23 09:38:29

I'd like to see the SQL trace from the database side to see what is being sent (or not being sent) on the unregister, as that should be clearing out the Contact field in the database. I want to see the SQL trace for the setup of the peer to the DB, and then the removal as well.

Showing the row in question after registration and after unregistering could be potentially useful.
By: Russell Bryant (russell) 2011-07-26 14:59:16.036-0500

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines