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 <[email protected]> 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 <[email protected]>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 >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> > > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
