[asterisk-bugs] [JIRA] (ASTERISK-14723) [patch] [regression] Simultaneous calls from same Call-ID silently ignored by asterisk

[Matt Jordan (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-14723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=156096#comment-156096 ] 

Matt Jordan edited comment on ASTERISK-14723 at 2/25/15 7:14 PM:
-----------------------------------------------------------------

I think I have found the root of this issue.

The issue is happening on calls arriving with the same call-id which are not immediately answered in the asterisk server.

I've tested 1.6.0.15 and the issue happens on this server as well. I've searched and here are the results:

On asterisk 1.6.0.15, the Flag SIP_PAGE2_DIALOG_ESTABLISHED has been introduced into chan_sip.c which is being set on incoming calls on Answer(). Asterisk 1.6.0.13 and prior did not have this flag.

In {{find_call()}} in chan_sip in line 6282 (approximately) it states

{code}
else
   found = (!strcmp(p->callid, callid) &&
   (!pedanticsipchecking || ast_strlen_zero(tag) || ast_strlen_zero(p->theirtag) || !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED) || !strcmp(p->theirtag, tag))) ;
{code}

Since callid's are the same the first condition is true. All other conditions are not true (since we are using pedantic and the tags are not the same) but if the call has not yet been answered the: {{!ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED)}} condition is true. Therefore asterisk considers the second INVITE message as part of the first call and wrongly Ignores it as duplicate.


was (Author: m0bius):
I think I have found the root of this issue.

The issue is happening on calls arriving with the same call-id which are not immediately answered in the asterisk server.

I've tested 1.6.0.15 and the issue happens on this server as well. I've searched and here are the results:

On asterisk 1.6.0.15, the Flag SIP_PAGE2_DIALOG_ESTABLISHED has been introduced into chan_sip.c which is being set on incoming calls on Answer(). Asterisk 1.6.0.13 and prior did not have this flag.

In find_call() in chan_sip in line 6282 (approximately) it states

else
   found = (!strcmp(p->callid, callid) &&
   (!pedanticsipchecking || ast_strlen_zero(tag) || ast_strlen_zero(p->theirtag) || !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED) || !strcmp(p->theirtag, tag))) ;

Since callid's are the same the first condition is true. All other conditions are not true (since we are using pedantic and the tags are not the same) but if the call has not yet been answered the: !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED) condition is true. Therefore asterisk considers the second INVITE message as part of the first call and wrongly Ignores it as duplicate.

> [patch] [regression] Simultaneous calls from same Call-ID silently ignored by asterisk
> --------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-14723
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-14723
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/General
>            Reporter: m0bius
>            Severity: Minor
>         Attachments: patch-1.6.1.1, patch-1.6.2.2
>
>
> Hello everyone,
> We have a follow-me system which terminates calls to an Asterisk server which holds registrations for our VoIP users. In our follow-me system we give the capability to the users to perform simultaneous follow-me to the Asterisk Server (thus ringing two different voip accounts).
> However I've noticed that on asterisk 1.6.1.1 and 1.6.1.4 when two calls are sent simultaneously to different dialled numbers with the same Call-ID, the second call does not enter the context. In a trace I did, I've seen that asterisk responds to the SIP INVITE with Trying; however, that calls stays there until it times out from the remote peer. 
> The same thing has been tested on Asterisk 1.6.0.7 and 1.6.0.13 and it works properly. I will attaching two traces (one from asterisk 1.6.0.7 and one from asterisk 1.6.1.4)



--
This message was sent by Atlassian JIRA
(v6.2#6252)