ASTERISK-14723: [patch] [regression] Simultaneous calls from same Call-ID silently ignored by asterisk

[Home]

Summary: ASTERISK-14723: [patch] [regression] Simultaneous calls from same Call-ID silently ignored by asterisk

Reporter: m0bius (m0bius) Labels:

Date Opened: 2009-08-27 05:40:27 Date Closed: 2015-02-25 19:24:35.000-0600

Priority: Minor Regression? Yes

Status: Closed/Complete Components: Channels/chan_sip/General

Versions: Frequency of
Occurrence

Related
Issues:
is related to ASTERISK-15023 [patch] Fix/improve transaction/dialog-matching in pedantic mode

Environment: Attachments: ( 0) patch-1.6.1.1
( 1) patch-1.6.2.2

Description: 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)

Comments: By: m0bius (m0bius) 2009-08-27 05:44:17

While tracing I noticed that the second call is not always ignored. The remote peers resends the INVITES and it may eventually enter the context.

By: Tilghman Lesher (tilghman) 2009-08-27 18:04:39

CLDs? CLI? In English, please?
By: Tilghman Lesher (tilghman) 2009-08-27 18:05:27

Also, is there a good reason why this issue was marked private?
By: m0bius (m0bius) 2009-08-28 02:43:46

I am sorry, when I said CLI I meant the CallerID number and CLD, the number called. I've marked it as private because of the IPs and phone numbers in the traces added.
By: Leif Madsen (lmadsen) 2009-09-15 11:58:25

If you could reproduce this in a lab and provide the traces without any incriminating evidence, then more people will be able to look at this issue. Currently only a couple of people with the appropriate access can review these traces.
By: m0bius (m0bius) 2009-09-23 06:04:26

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.
By: m0bius (m0bius) 2009-09-23 07:33:50

Additionally on asterisk 1.6.1.1 I've seen:

on function find_call() line 6428:

arg.tag = ""; /* make sure tag is never NULL */

If pedantic is on, the find_call() searched for the From/To tag and sets it to the 'tag' variable. However the arg.tag variable is never set to anything. Thus well the callback function find_call_cb() is called, ast_strlen_zero(arg->tag) is always true thus changing the found variable to permanently true, marking the message as part on the sip dialog and as duplicate.

I am not sure if this is correct but setting arg.tag = tag if pedantic and removing the !ast_test_flag(&p->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED) condition from find_call_cb() the calls are processed normally as they should.
By: Leif Madsen (lmadsen) 2009-09-23 09:48:23

Great thanks for the information! I'm setting this to Acknowledged.
By: m0bius (m0bius) 2009-09-28 08:48:50

FYI, I have asterisk 1.6.1.1 with the changes I've suggested above in production for a few days now, and no problem has been spotted yet.

I think we can remove the traces and open this ticket publicly.
By: Leif Madsen (lmadsen) 2009-09-28 14:15:05

Changed back to public per the reporter after removing traces.
By: Matthew Nicholson (mnicholson) 2009-10-21 15:22:26

Your UAC should not be sending the same Call-ID on two different INVITE messages. I don't believe this is a bug in asterisk, although I may have mis-understood something.
By: m0bius (m0bius) 2009-10-21 17:20:49

From my understanding in order to fully implement the RFC a call is considered unique on not just the call-id but on various other sip attributes such as the From and To as well as the Tags that follow them. (That's the meaning of the pedantic option in sip.conf) - Correct me please if I am wrong.

The question is not why the UAC is sending the same Call-Id on two different invites. The question should be why asterisk on pedantic=yes does not take into consideration the To tag. And why the SIP Dialog is considered established only AFTER the call has been answered.

If Asterisk is playing the role of a SIP Proxy it will never Answer() the calls but redirect them unanswered. With this implementation all Dialogs would be considered not established.
By: Matthew Nicholson (mnicholson) 2009-10-22 08:04:30

I reviewed the RFC. It looks like you are correct. I will look into this further.
By: David Woolley (davidw) 2009-10-22 08:35:32

I thought the RFC said that you must always use the same From and To with a given call ID, but only because some earlier versions of SIP matched on From and To. The impression I got was that one should ignore From and To when matching for current SIP versions.

" Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address. The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog."

" Usage of the URI from the To and From fields in the original
request within subsequent requests is done for backwards
compatibility with RFC 2543, which used the URI for dialog
identification. In this specification, only the tags are used for
dialog identification. It is expected that mandatory reflection
of the original To and From URI in mid-dialog requests will be
deprecated in a subsequent revision of this specification."

Tags are used to identify dialogs within a call, not to identify the call.
By: David Woolley (davidw) 2009-10-22 09:16:02

Ah! Part of the confusion here is that "call" is being used when what is actually being talked about is a "dialog"!

Dialogs don't require a From or To match, only From Tag and To Tag matches.
By: David Woolley (davidw) 2009-10-23 05:55:27

Looks like this might just have been fixed in ASTERISK-1592116. Normally I would have suggested that that one was the duplicate, but it contains a patch and this one doesn't! It's also got a more correct summary.
By: klaus3000 (klaus3000) 2009-10-23 10:39:07

Just a note: If an incoming call is parallel forked on a previous hop (e.g. SIP proxy) as in the following scenario

<pre>
+----------+
INV group -----> proxy ----INV user1------>| Asterisk |
\ | Server |
---INV user2------>| |
+----------+
</pre>
then on the first hand this is about identifiying transactions, not dialog. So in this case, from transaction point of view, the From/To-tags and callid are irrelevant - there are 2 different transactions identified by different branch parameter in topmost Via header.

Of course the problem arise to more parameter analysis when actually deciding what to do. Asterisk could answer (based on extensions.conf) both branches, which can cause confusion to the caller, as then there are 2 dialogs established. The caller can be able to handle this situation and has 2 calls open - I do not know any softwarwe which supports it, usually the caller's client will send a BYE to one of the callees (or crash :-).

To allow creation of 2 dialogs/calls Asterisk needs proper dialog identification. Callid,tags and remote contact will be identical, thus only the local contact can be used to identifiy the 2 dialogs.

Nevertheless establishing 2 dialogs usually will only confuse the caller and IMO Asterisk should just reject the second branch, e.g. with 486.

By: David Woolley (davidw) 2009-10-23 11:16:25

Surely it is an issue for the proxy that allows the establishment of two dialogs to deal with if its client will get confused. I would think Asterisk should treat them as completely independent.

I presume the reason for doing this would be the same as for using & in the Asterisk Dial application and a proxy doing it would normally cancel all but one of them, rather than sending the final ACK.
By: klaus3000 (klaus3000) 2009-10-23 11:49:50

No, this is not an issue for the proxy. The proxy just forks the call as described in the RFC. The UAS must be able to identify these 2 branches as belonging to the same call, and the UAC must be capable of handling the race condition of receiving 200 OK from multiple UAS. It is clearly specified that this race-condition is not be handled by the proxy, but by the UAC!

If the 2 branches are received at Asterisk, there is still no dialog - just a transcation with mutliple branches. Only by answering the branches a dialog will be established.

There is much difference between a proxy doing parallel forking and Asterisk using Dial(user1&user2). Asterisk is not a proxy - it maintains 2 calls on the outgoing side (different callid, tags, ...) whereas a proxy has just one (forked) call with multiple branches (same callid, tags but different branch parameter).

Conclusion: The UAC should be capable of resolving the race condition. But IMO, if the multiple branches are handled by the same UAS (i.e. Asterisk), the UAS should already apply some intelligence to avoid the race condition (e.g. reject the second branch with 486).

Anyway - what Asterisk is doing (ignoring the sceond branch) is wrong - it has to either create a second dialog or reject the second branch.
By: David Woolley (davidw) 2009-10-23 11:56:41

Rejecting will make the use case that started this issue fail. I believe that the patch in ASTERISK-15023 attempts resolve it by creating the second dialog.
By: klaus3000 (klaus3000) 2009-10-23 12:06:18

I wonder how do you think the caller should handle this. In the scenario I sketched, if both branches will be accepted and Answered(), the caller will have 2 dialogs established. Thus, the caller will received 2 RTP streams and has to send 2 RTP streams. Shall the caller just mix the streams?

I think the problem is just the "ignoring" - because this will cause lots of retransmissions and weird signaling between the proxy and Asterisk.
By: David Woolley (davidw) 2009-10-23 12:45:57

If two OKs get back to the caller, the RFC seems to require a valid acceptance for both of them. The caller is then allowed to send BYE, immediately.

The very final part of section 16.7 says, effectively, that on forwarding a 200 OK, the proxy MUST generate a Cancel for all the other forked calls. However, it also says that a race condition can result in more then one of those calls having a 200 OK response.

Stateless proxies cannot fork.
By: klaus3000 (klaus3000) 2009-10-23 13:11:04

That is what I already said: If a called is forked and multiple branches are answered at the same time this is a race condition (which must be handled by the caller, usually by sending BYE to all but one callees).

Back to the original problem - Asterisk does not respond to additional branches of an INVITE transaction. There are 2 solutions: (A) Either reject the additional branches or (B) accept (and enter dialplan execution) for all branches.

(B) is probably difficult to implement (correct dialog identification) and generates a race condition. As race conditions are a bad thing, Asterisk should not generate them by purpose.

(A) should be much easier to implement, does not cause a race conditions and does not cause problems with bad implemented UACs.
By: David Woolley (davidw) 2009-10-23 13:20:21

Just to make it clear to m0bius, I believe you are proposing that this issue be closed with a won't fix status and the patch for ASTERISK-15023 be rejected, but the issue, maybe, continued with a different proposed solution.

I have a feeling we are going to be asked to take this to the mailing list.
By: klaus3000 (klaus3000) 2009-10-23 13:34:12

Seems like m0bius' solution implements (B).

The more I think about it - mabye (B) is the better solution. It may cause race conditions, but on the other hand is more flexible.

I do not know how/if this is fixed in ASTERISK-1592116.

PS: One more evidence that the pedantic option should be removed and Asterisk should always be RFC conform.
By: m0bius (m0bius) 2010-02-12 04:03:31.000-0600

Sorry for taking so long to respond. I would like to share with everyone that the fix mentioned above has been working on production environment for a few months without any issues.

I am not entirely sure that this still is the best way to go, but it could serve as a workaround until then.
By: Olle Johansson (oej) 2010-02-15 02:48:29.000-0600

Klaus, I don't think we should reject the second call leg. Imagine forking to a phone and a voicemail extension that waits 30 secs and then answers. We need to support both call legs. If the forks has the same r-URI, then we can respond with a "merged" message.

Kevin was working on code for this on SIPit in New Hampshire.
By: klaus3000 (klaus3000) 2010-02-15 03:45:30.000-0600

Probably you are right. The second branch should be accepted too. But I think this requires correct tag handling in Asterisk (pedantic=yes).
By: Mikael F (mikaelf) 2010-02-19 04:35:22.000-0600

I am sorry if this is not the place to post this but I think I have the same problem, asterisk version 1.6.2.0, pedantic is set to yes.

Two incomming calls to the asterisk from the same caller is sent, second invite gets: "Ignoring this INVITE request":

INVITE sip:firstnumber@asteriskserver SIP/2.0
Record-Route: <sip:serversendinginvites;ftag=a08d60977ceb7bd4d98241e67dff284eo;lr>
Via: SIP/2.0/UDP serversendinginvites;branch=z9hG4bKf80b.94fdac8c3f8f9ad3283d7dbe8ac39a90.0
Via: SIP/2.0/UDP serversendinginvites:5061;branch=z9hG4bK7be758dae3de7a79369bbd549678c890;rport=5061
Max-Forwards: 16
From: <sip:originatingcaller@serversendinginvites>;tag=a08d60977ceb7bd4d98241e67dff284eo
To: <sip:firstnumber@serversendinginvites>
Call-ID: EA0785B5-1C7211DF-99B3A4EC-DCEB9CE0@serverip
CSeq: 200 INVITE
Contact: Anonymous <sip:serversendinginvites:5061>
Expires: 300
User-Agent: serversendinginvites
cisco-GUID: 544724832-511663812-3825585790-2681720812
h323-conf-id: 544724832-511663812-3825585790-2681720812
Content-disposition: session
Content-Length: 415
Content-Type: application/sdp

INVITE sip:secondnumber@asteriskserver SIP/2.0
Record-Route: <sip:serversendinginvites;ftag=67ec0ff3c23d9b35b737206e677cc802o;lr>
Via: SIP/2.0/UDP serversendinginvites;branch=z9hG4bKf80b.90528f5579fe29e42359a222ba8074ea.0
Via: SIP/2.0/UDP serversendinginvites:5061;branch=z9hG4bKb1cb9f7680bc7f3ed846dd3c2d9dbac9;rport=5061
Max-Forwards: 16
From: <sip:originatingcaller@serversendinginvites>;tag=67ec0ff3c23d9b35b737206e677cc802o
To: <sip:secondnumber@serversendinginvites>
Call-ID: EA0785B5-1C7211DF-99B3A4EC-DCEB9CE0@serverip
CSeq: 200 INVITE
Contact: Anonymous <sip:serversendinginvites:5061>
Expires: 300
User-Agent: serversendinginvites
cisco-GUID: 1293890127-1580750916-857664346-4274469766
h323-conf-id: 1293890127-1580750916-857664346-4274469766
Content-disposition: session
Content-Length: 415
Content-Type: application/sdp

Ignoring this INVITE request
By: klaus3000 (klaus3000) 2010-02-19 05:18:09.000-0600

This trace looks strange. The requests are almost identical, but have a different from-tag and also have different branch-ids in all Via headers. Which useragent/proxy are you using?

Shouldn't Asterisk handle this correctly as the From-tag differs?
By: Mikael F (mikaelf) 2010-02-19 06:16:33.000-0600

SIP Express Router is the user agent sending the two invites.
By: klaus3000 (klaus3000) 2010-02-19 06:39:51.000-0600

AFAIK SER never changes from-tag or Via headers of client. Further, if this request is really forked by SER the branch id in topmost Via header should be the same except the last digit (.0 and .1).

Thus I guess the forking is already done before the call is sent to SER.

Anyway, if the trace you presented is correct, then Asterisk should handle this correctly as there are different from-tags (or you have found another bug in Asterisk)
By: Mikael F (mikaelf) 2010-02-19 07:04:32.000-0600

This is the correct SIP trace for the call - the second ivnite always gets "Ignoring this INVITE request" - but I have no idea why.

Ofc I can solve it by configuring the number dialed on the SER (which in turn dials the two numbers on the asterisk) on the asterisk instead - and then make it call the two numbers.

This works but it makes things a bit more clumsy for me...
By: klaus3000 (klaus3000) 2010-02-19 08:27:41.000-0600

If there is one INVITE from the client to SER, and SER make parallel forking, then, why:
- are from tags different?
- Via branch ids different?

There must be somebody mangling the tags.

INVITE sip:firstnumber@asteriskserver SIP/2.0
Via: SIP/2.0/UDP serversendinginvites;branch=z9hG4bKf80b.94fdac8c3f8f9ad3283d7dbe8ac39a90.0
Via: SIP/2.0/UDP serversendinginvites:5061;branch=z9hG4bK7be758dae3de7a79369bbd549678c890;rport=5061
From: <sip:originatingcaller@serversendinginvites>;tag=a08d60977ceb7bd4d98241e67dff284eo

INVITE sip:secondnumber@asteriskserver SIP/2.0
Via: SIP/2.0/UDP serversendinginvites;branch=z9hG4bKf80b.90528f5579fe29e42359a222ba8074ea.0
Via: SIP/2.0/UDP serversendinginvites:5061;branch=z9hG4bKb1cb9f7680bc7f3ed846dd3c2d9dbac9;rport=5061
From: <sip:originatingcaller@serversendinginvites>;tag=67ec0ff3c23d9b35b737206e677cc802o

Anyway, if these are really the message, then there is a bug in Asterisk.
By: Mikael F (mikaelf) 2010-02-19 08:44:35.000-0600

I can't answer why as I'm just a mortal ;-) The sip trace above is a direct trace of a simultaneous follow me sent from the SER.

Specifically it's a porta one server (which is based on SER) that sends the simultaneous follow me.

I hope this was the right place to add this (as it seemed the above problem was related to mine, but I feel too new to make that judgement).

If any administrator wants the complete sip trace I would be happy to send it privately, just drop me a mail, should it be needed for further progress.
By: klaus3000 (klaus3000) 2010-02-19 09:24:58.000-0600

Ok. Maybe portaone SER mangles tags.

Anyway, I try to reproduce the problem.
By: Mikael F (mikaelf) 2010-02-24 04:47:52.000-0600

Any progress?
By: Mikael F (mikaelf) 2010-02-24 05:48:02.000-0600

The problem is also the same when a call is made to the asterisk and the asterisk user has DND on the phone. If my SER then sends a new request to another user on the asteris, then the invite will be ignored too as it comes from the same caller id.

So same problem there - same call-id and it will ignore the next invites...
By: klaus3000 (klaus3000) 2010-02-24 06:15:24.000-0600

are you sure that "pedantic=yes"?
By: Mikael F (mikaelf) 2010-02-24 06:42:53.000-0600

I have tried both with the same result, pedantic is on at the moment:

sip.conf:

[general]
bindport=5060
bindaddr=0.0.0.0
srvlookup=no
disallow=all
allow=ulaw
allow=alaw
defaultexpirey=120
registertimeout=30
maxexpirey=3600
ignoreregexpire=yes
registerattempts=0
context=default
externip=xxx.xxx.xxx.xxx
useragent=42
pedantic=yes
By: m0bius (m0bius) 2010-02-24 07:51:44.000-0600

Mikaelf, try out what I've mentioned above on the 23rd of September about the modifications on find_call with pedantic=yes. It should work
By: Mikael F (mikaelf) 2010-02-24 09:39:14.000-0600

Oh ok, I thought it was already actualized in the version I run (1.6.2) since it sais:

2009-10-23 04:41 alexh Asterisk Version => Older 1.6.1

But I will try this patch out, I guess it's the "Index: asterisk-1.6.speakup.1.4/channels/chan_sip.c" that I should use only?

I feel a bit confused by the jargon above sorry :-)
By: Mikael F (mikaelf) 2010-02-24 10:38:18.000-0600

I tried the patch on my current 1.6.2 source and I'm not surprised that it fails - I suspect a lot has happened in the file since the patch was written.

Any good way how I go about this? Do I need to install an older version of asterisk to get this to work or will it work if I try to find and download an older version of chan_sip.c only and try to recompile 1.6.2 with the new chan_sip.c?

My advanced excuses if questions is inappropriate here...
By: m0bius (m0bius) 2010-02-24 11:09:51.000-0600

<inline patch removed by lmadsen>

By: m0bius (m0bius) 2010-02-24 11:10:15.000-0600

Sorry, try to apply this over channels/chan_sip.c.
By: Mikael F (mikaelf) 2010-02-24 14:47:31.000-0600

chan_sip.c: In function â??find_call_cbâ??:
chan_sip.c:7312: error: invalid lvalue in assignment
chan_sip.c: In function â??find_callâ??:
chan_sip.c:7375: error: invalid lvalue in assignment
chan_sip.c:7342: warning: unused variable â??tagâ??
make[1]: *** [chan_sip.o] Error 1
make: *** [channels] Error 2

Code for the lines:

7312: ! found = ast_strlen_zero(arg->tag) || ast_strlen_zero(p->theirtag) || !strcmp(p->theirtag, arg->tag);

7375: ! arg.tag = (req->method == SIP_RESPONSE) ? totag : fromtag;

7342: char *tag = ""; /* note, tag is never NULL */
By: Mikael F (mikaelf) 2010-02-25 08:17:00.000-0600

Just me that thought that the exclamation marks was some neat c-syntax I hadn't seen before but it was just to mark the lines that was changed, doh!

I couldn't run "patch" to apply the patch since there's different line numbers in my file.

Thanks a lot for the help m0bius, I will try the patch now.
By: Mikael F (mikaelf) 2010-02-25 15:07:22.000-0600

Woho! Works! Thanks again m0bius!
By: Leif Madsen (lmadsen) 2010-03-03 12:14:07.000-0600

m0bius: Please provide patches as an attachment to this issue so it can be tracked appropriately. I have modified your comment with the inline comment as inline code is not allowed.
By: Mikael F (mikaelf) 2010-03-11 03:33:30.000-0600

I tried this on Asterisk 1.4.17 and got the same problem there, FYI.
By: Leif Madsen (lmadsen) 2010-03-15 13:14:16

1.4.17 is QUITE old -- the latest version is 1.4.30.
By: Mikael F (mikaelf) 2010-03-16 04:14:33

Yeah it's on a server I have no intention of upgrading but just giving you heads up that this may be a problem not limited to 1.6.x versions.
By: Raul Gomez (rhgomez) 2010-06-02 12:08:44

Where can I get m0bius patch? I'm running Asterisk 1.6.2.7
By: Mikael F (mikaelf) 2010-06-03 04:41:38

Look for these lines and change them to this:

7312: found = ast_strlen_zero(arg->tag) || ast_strlen_zero(p->theirtag) || !strcmp(p->theirtag, arg->tag);

7375: arg.tag = (req->method == SIP_RESPONSE) ? totag : fromtag;

They may not be at just those lines but that's all you need to change to fix it, they should at least be close to the line numbers above.
By: m0bius (m0bius) 2010-06-03 09:52:03

I've uploaded the same patch for 1.6.1.1 and 1.6.2.2. It's the same thing, only different lines.
By: Raul Gomez (rhgomez) 2010-06-03 22:58:17

Thanks MikaelF, The changes worked great!
The lines I changed at chan_sip.c for 1.6.2.7 were 7316 and 7367 respectively.
I still cannot find the patch file attached by m0bius, so I needed to change those lines manually (I only see the new Tag "attachment_tag").
By: Leif Madsen (lmadsen) 2010-06-08 10:29:53

Patches are attachments to the issue near the top of the page.
By: Olle Johansson (oej) 2010-06-08 10:35:40

What's the status with Kevin's work?
By: philipp2 (philipp2) 2010-06-09 05:52:19

ASTERISK-16230 is possibly related to this
By: Leif Madsen (lmadsen) 2010-06-14 14:10:25

@oej: the work has been taken over by mmichelson.
By: Leif Madsen (lmadsen) 2011-05-06 18:55:39

This issue is pretty old now, and it would be ideal if someone could comment on if this issue may now be resolved. A lot of work has been done in areas similar to this, and someone going through and testing again would be ideal. Beyond that, it would be nice to know if we're at the same spot, or if we're closer, but there are still things to clean up. If that is the case, a detailed analysis would be extremely helpful.

I asked mmichelson about this issue today, and he doesn't quite recall it, but here is his statement:

<putnopvut> Taking the issue as stated, I think it *may* be fixed though. I think it may be worthwhile to do a ping on the issue since lots of work has been done to properly ID calls. One of the big things that was done was to observe the branch parameter in Via headers, but I'm not sure this issue deals with that.
By: Matt Jordan (mjordan) 2015-02-25 19:24:23.317-0600

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.