Hi all,
I've run into a potential error: call scenario towards a SIP trunk where the timing of received SIP signals causes DUM to inadvertently, or by design, take different paths.
The call scenario is as follows:
UAC UAS(SIP trunk)
--- ---
|-------- INVITE -------->|
|<------ 100 Trying ------|
|<- 183 Session Progress -|
|--------- PRACK -------->|
|<--------200 OK ---------|
|<----- 180 Ringing ------|
|--------- PRACK -------->|
|<-481 Call/Transaction --|
|<--600 Busy everywhere --|
It is the timing issue between signals '481' and '600' which is causing different paths.
If there's some time in between these signals, signal '481' manages to run its course which includes the deletion of the InviteSession and its dialog.
On the reception of signal '600', no dialog is located, therefore a new dialog as well as a new InviteSession is created.
Within the InviteSession, method 'ClientInviteSession::dispatchStart' is called which notifies the application layer through events 'onFailure' and 'onTerminated' of the reception of signal 600.
Now if there is no time in between these signals things happen differently.
Signal '481' runs its course, but the deletion of the associated InviteSession is not executed because signal '600' is next in line to be processed.
Therefore the dialog is located and its InviteSession is called ending up in 'InviteSession::dispatchTerminated' which simply starts tearing things down. Therefore the application layer does not receive any
'onFailure' or 'onTerminated' events of the reception of signal '600'.
Or
Similar to above flow but with the twist where only the InviteSession is deleted, and the dialog is in mDestroying, when signal '600' is processed.
This results in the message getting dropped and no events sent to application layer of the reception of signal '600'.
Tested using resiprocate 1.10.1 and 1.10.2.
BR
/Janne