[Home]

Summary:ASTERISK-11183: Originating calls using Asterisk manager - reinvites receive 491 Request Pending rather than immediate response
Reporter:Andrew Smith (eurodrew555)Labels:
Date Opened:2008-01-09 07:01:02.000-0600Date Closed:2011-06-07 14:02:54
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:It would appear that there is a problem with their ao2iteration routine

If we originate a call using the Manager and check the DEBUG

Action: Originate
Channel: sip/hgc
Exten: 9123
Context: internal
Priority: 1

Then when the call is answered

[Jan  9 11:52:04] DEBUG[4814] chan_sip.c: Acked pending invite 102

On SVN version 96932 we receive an “Acked Pending Invite” and the pendinginvite variable is reset to ZERO but we don’t get this on SVN version 97077, this then causes a problem when we try to use our Linksys SPA 942 to hold the call, which it does by sending another invite. We receive a 491 response and it keep retrying.

It eventually does place the call on hold but it takes around 2 minutes.


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

The code that has changed is in chan_sip.c (posting here as it is very short)

The old code was like this

       for (cur = p->packets; cur; prev = cur, cur = cur->next) {

               if ((cur->seqno == seqno) && ((ast_test_flag(cur, FLAG_RESPONSE)) == resp) &&

                       ((ast_test_flag(cur, FLAG_RESPONSE)) ||

                        (!strncasecmp(msg, cur->data, strlen(msg)) && (cur->data[strlen(msg)] < 33)))) {

The new code like this

       ao2i = ao2_iterator_init(p->packets, 0);
       while ((cur = ao2_iterator_next(&ao2i))) {
               if ((cur->seqno == seqno) && ((ast_test_flag(cur, FLAG_RESPONSE)) == resp) &&

                       ((ast_test_flag(cur, FLAG_RESPONSE)) ||
                        (!strncasecmp(msg, cur->data, strlen(msg)) && (cur->data[strlen(msg)] < 33)))) {

Comments:By: Tilghman Lesher (tilghman) 2008-01-18 00:58:45.000-0600

The code relating to this was reverted, so this should no longer be an issue.