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 timo.reimann@1und1.de 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.h...
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 <jason.penton@gmail.com mailto:jason.penton@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@1und1.de <mailto:timo.reimann@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@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org <mailto:sr-dev@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev