[sr-dev] Dialog2

[Richard Good]

Hi,

I am working with Jason on implementing the basics for the dialog_2 module.

I've got a question concerning the concurrently confirmed call scenario.  If
multiple 200 OKs are received very close to the same time, the new dialog
design proposal says we should create a separate dialog_in structure and
assign a different DID to it, essentially creating multiple dialog_in
structures and multiple dialog_out structures.

Should we not just absorb/ignore the subsequent 200 OK's in this case?  I
would imagine that if a SIP client received multiple 200 OKs it would ACK
the first and ignore the rest as it is effectively already in a call
(haven't checked the specs for this yet).  So why should we track this in
the dialog module?  If we just absorb/ignore the subsequent 200 OK the
client sending this 200 OK would eventually timeout due to no ACK.

Regards
Richard.


On 7 September 2011 12:50, Jason Penton <jason.penton at gmail.com> wrote:

> Great, thanks Timo.
>
> We're going to go ahead and see what we can come up with. We are initially
> thinking of building a new module from scratch, obv. with a lot of reuse
> from the original dialog module. Our goal then is to get all the correct
> data structures in place (in and out tables, etc) and being built up
> correctly using a state machine. Once we're are there we will create a
> branch for everyone else to help and provide feedback.
>
> We will def. need help when it comes to termination of early dialog, etc -
> but I think we will get a very good start in.
>
> Cheers
> Jason
>
>
> On Wed, Sep 7, 2011 at 11:40 AM, Timo Reimann <timo.reimann at 1und1.de>wrote:
>
>> On 07.09.2011 11:22, Timo Reimann wrote:
>> > If you find more points to discuss, I (and Iñaki and others possibly
>> > too) would be glad to share in. In addition, I think that opening up
>> > another branch for the new dialog module at a rather early stage of
>> > development might be a good idea in order to get more eyes on the code.
>>
>> One more comment: If the new implementation gives you an opportunity to
>> redo the reference counting portion of the module, I suggest to take it.
>> Reference counting management has grown into the most complicated part
>> of the module, and thus can surely benefit from a new, fresh approach.
>>
>>
>> --Timo
>>
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110915/504fc475/attachment.htm>