[OpenSIPS-Devel] Limitations of dialog module
Dan Pascu
dan at ag-projects.com
Wed Sep 9 16:57:49 CEST 2009
On 8 Sep 2009, at 16:34, Bogdan-Andrei Iancu wrote:
> Iñaki Baz Castillo wrote:
>>
>> 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......
I agree. The proxy should not discard anything. From UAC2's
perspective the call is there, it only misses an ACK. It will keep
retransmitting the 200 OK, until it decides to give up, unless is an
UAC that was configured to ignore the missing ACK in which case it
will consider that it has the call anyway and will act accordingly.
>
>
> 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
Is this easier to do than to simply forward and make clones of the
dialog?
>
> Regards,
> Bogdan
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
--
Dan
More information about the Devel
mailing list