Hi Timo, Thanks for the detailed feedback. Agreed that it is necessary and we will incorporate a basic attempt of this into the dialog_2 module.
Regards Richard. On 16 September 2011 12:42, Timo Reimann <[email protected]> wrote: > Hi Richard, > > > On 15.09.2011 16:33, Richard Good wrote: > > 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. > > UACes receiving multiple 200 OK responses to the same INVITE request are > required to ACK both. From there, it is completely up to the UAC how to > deal with having two confirmed dialogs. While sending a BYE to one of > the dialogs is a valid (and likely) option, it could just as well put > one of them on hold, do nothing, or something completely different we > cannot presume. That's the reason why you cannot absorb/ignore > subsequent 200 OK responses but need to maintain and process two > distinct dialogs. > > See also Jonathan Rosenberg's response to this question on the > sip-implementors mailing list: > > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-April/000935.html > > Back in March 2010, I discussed this very issue on the sr-dev mailing > list, primarily with Iñaki. If you like to dig into the details, here's > the link: > > http://lists.sip-router.org/pipermail/sr-dev/2010-March/006631.html > > > HTH, > > --Timo > > > > > On 7 September 2011 12:50, Jason Penton <[email protected] > > <mailto:[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] > > <mailto:[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] <mailto:[email protected]> > > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > > > > > > > > _______________________________________________ > > sr-dev mailing list > > [email protected] <mailto:[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
