[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=225120#comment-225120 ] 

Matt Jordan commented on ASTERISK-14723:
----------------------------------------

I took another pass through the {{chan_sip}} after looking at this issue, and I suspect this is no longer a bug. The logic that handles how we match a dialog has changed substantially since [~m0bius]'s earlier comments. In particular, how we match the {{To}} tag appears to account for the situation described here:

{code}
		/* Verify totag if we have one stored for this dialog, but never be strict about this for
		 * a response until the dialog is established */
		if (!ast_strlen_zero(sip_pvt_ptr->theirtag) && ast_test_flag(&sip_pvt_ptr->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED)) {
			if (ast_strlen_zero(arg->totag)) {
				/* missing totag when they already gave us one earlier */
				return SIP_REQ_NOT_MATCH;
			}
			/* compare the totag of response with the tag we have stored for them */
			if (strcmp(arg->totag, sip_pvt_ptr->theirtag)) {
				/* totag did not match what we had stored for them. */
				char invite_branch[32] = { 0, };
				if (sip_pvt_ptr->invite_branch) {
					snprintf(invite_branch, sizeof(invite_branch), "z9hG4bK%08x", (unsigned)sip_pvt_ptr->invite_branch);
				}
				/* Forked Request Detection
				 *
				 * If this is a 200ok response and the totags do not match, this
				 * might be a forked response to an outgoing Request. Detection of
				 * a forked response must meet the criteria below.
				 *
				 * 1. must be a 2xx Response
				 * 2. call-d equal to call-id of Request. this is done earlier
				 * 3. from-tag equal to from-tag of Request. this is done earlier
				 * 4. branch parameter equal to branch of inital Request
				 * 5. to-tag _NOT_ equal to previous 2xx response that already established the dialog.
				 */
				if ((arg->respid == 200) &&
					!ast_strlen_zero(invite_branch) &&
					!ast_strlen_zero(arg->viabranch) &&
					!strcmp(invite_branch, arg->viabranch)) {
					return SIP_REQ_FORKED;
				}

				/* The totag did not match the one we had stored, and this is not a Forked Request. */
				return SIP_REQ_NOT_MATCH;
			}
		}
{code}

I'm going to go ahead and Close this issue. If someone is using a supported version of Asterisk and this is still an issue, a pcap showing it would help clarify exactly what is being sent to Asterisk in this scenario - but in any case, comment here and I'd be happy to reopen it.

> [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)