[OpenSIPS-Devel] Limitations of dialog module

[Bogdan-Andrei Iancu]

Iñaki Baz Castillo wrote:
>> This solves most of the problems you described here, but of course, the
>> modules on top of dialog module (like callcontrol, mediaproxy, etc) needs to
>> be also tuned to use the early dialog support.
>>
>> What is left to do (from my perspective):
>>
>> - multi 200 OK answers - this require support for sort of dialog cloning
>> (when more than one 200 OK is received) - I prefer to split the current
>> dialog and to let the UAC to decide what dialog to keep alive and which to
>> BYE
>>     
>
> IMHO, and according to a draft updating RFC 3261, the second 200 could
> be absorbed by the proxy instead of forwarded upstream. For this, the
> transaction should not be terminated upon receipt of the first 200,
> but remain in memory for a while (as the draft states).
>   
This is what the TM does right now - it keeps the transaction in mem, 
but also it allow all to received 200 OK to be sent to the UAC.

> This would simplify all this stuf a lot. Also, who in the world wants
> to receive two 200 for an INVITE? XDDD
>   
I agree but what should happen in the following scenario:

1) UAC sends INVITE

2) proxy forks the call to UAS1 and UAS2

3) both UAS1 and UAS2 send 200 OK in the same time

4) right now proxy will send both 200 OK to UAC

5) UAC will ACK both, keep one and BYE the other


So, if we simply discard the second 200OK, what will happen with UAC2? 
it will think it is in a call... waiting for ACK......


At a moment I had in mind the option for the dialog module to ACK and 
BYE all the sequential 200 OK replies without sending anything to UAC

Regards,
Bogdan