[asterisk-bugs] [Asterisk 0015784]: Simultaneous calls from same Call-ID silently ignored by asterisk

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=15784 
====================================================================== 
Reported By:                m0bius
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   15784
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           SVN 
JIRA:                       SWP-221 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2009-08-27 05:40 CDT
Last Modified:              2009-10-23 11:49 CDT
====================================================================== 
Summary:                    Simultaneous calls from same Call-ID silently
ignored by asterisk
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)
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0016116 [patch] Fix/improve transaction/dialog-...
====================================================================== 

---------------------------------------------------------------------- 
 (0112668) klaus3000 (reporter) - 2009-10-23 11:49
 https://issues.asterisk.org/view.php?id=15784#c112668 
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2009-10-23 11:49 klaus3000      Note Added: 0112668                          
======================================================================