Hi Timo,<div><br></div><div>Thanks for the detailed feedback. Agreed that it is necessary and we will incorporate a basic attempt of this into the dialog_2 module.<br><br></div><div>Regards</div><div>Richard.</div><div><br>
</div><div><br><div class="gmail_quote">On 16 September 2011 12:42, Timo Reimann <span dir="ltr"><<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Richard,<br>
<div class="im"><br>
<br>
On 15.09.2011 16:33, Richard Good wrote:<br>
> I am working with Jason on implementing the basics for the dialog_2 module.<br>
><br>
> I've got a question concerning the concurrently confirmed call scenario.<br>
> If multiple 200 OKs are received very close to the same time, the new<br>
> dialog design proposal says we should create a separate dialog_in<br>
> structure and assign a different DID to it, essentially creating<br>
> multiple dialog_in structures and multiple dialog_out structures.<br>
><br>
> Should we not just absorb/ignore the subsequent 200 OK's in this case?<br>
> I would imagine that if a SIP client received multiple 200 OKs it would<br>
> ACK the first and ignore the rest as it is effectively already in a call<br>
> (haven't checked the specs for this yet). So why should we track this<br>
> in the dialog module? If we just absorb/ignore the subsequent 200 OK<br>
> the client sending this 200 OK would eventually timeout due to no ACK.<br>
<br>
</div>UACes receiving multiple 200 OK responses to the same INVITE request are<br>
required to ACK both. From there, it is completely up to the UAC how to<br>
deal with having two confirmed dialogs. While sending a BYE to one of<br>
the dialogs is a valid (and likely) option, it could just as well put<br>
one of them on hold, do nothing, or something completely different we<br>
cannot presume. That's the reason why you cannot absorb/ignore<br>
subsequent 200 OK responses but need to maintain and process two<br>
distinct dialogs.<br>
<br>
See also Jonathan Rosenberg's response to this question on the<br>
sip-implementors mailing list:<br>
<br>
<a href="https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-April/000935.html" target="_blank">https://lists.cs.columbia.edu/pipermail/sip-implementors/2001-April/000935.html</a><br>
<br>
Back in March 2010, I discussed this very issue on the sr-dev mailing<br>
list, primarily with Iņaki. If you like to dig into the details, here's<br>
the link:<br>
<br>
<a href="http://lists.sip-router.org/pipermail/sr-dev/2010-March/006631.html" target="_blank">http://lists.sip-router.org/pipermail/sr-dev/2010-March/006631.html</a><br>
<br>
<br>
HTH,<br>
<br>
--Timo<br>
<div class="im"><br>
<br>
<br>
> On 7 September 2011 12:50, Jason Penton <<a href="mailto:jason.penton@gmail.com">jason.penton@gmail.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:jason.penton@gmail.com">jason.penton@gmail.com</a>>> wrote:<br>
><br>
> Great, thanks Timo.<br>
><br>
> We're going to go ahead and see what we can come up with. We are<br>
> initially thinking of building a new module from scratch, obv. with<br>
> a lot of reuse from the original dialog module. Our goal then is to<br>
> get all the correct data structures in place (in and out tables,<br>
> etc) and being built up correctly using a state machine. Once we're<br>
> are there we will create a branch for everyone else to help and<br>
> provide feedback.<br>
><br>
> We will def. need help when it comes to termination of early dialog,<br>
> etc - but I think we will get a very good start in.<br>
><br>
> Cheers<br>
> Jason<br>
><br>
><br>
> On Wed, Sep 7, 2011 at 11:40 AM, Timo Reimann <<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a><br>
</div><div class="im">> <mailto:<a href="mailto:timo.reimann@1und1.de">timo.reimann@1und1.de</a>>> wrote:<br>
><br>
> On 07.09.2011 11:22, Timo Reimann wrote:<br>
> > If you find more points to discuss, I (and Iņaki and others<br>
> possibly<br>
> > too) would be glad to share in. In addition, I think that<br>
> opening up<br>
> > another branch for the new dialog module at a rather early<br>
> stage of<br>
> > development might be a good idea in order to get more eyes on<br>
> the code.<br>
><br>
> One more comment: If the new implementation gives you an<br>
> opportunity to<br>
> redo the reference counting portion of the module, I suggest to<br>
> take it.<br>
> Reference counting management has grown into the most<br>
> complicated part<br>
> of the module, and thus can surely benefit from a new, fresh<br>
> approach.<br>
><br>
><br>
> --Timo<br>
><br>
> _______________________________________________<br>
> sr-dev mailing list<br>
</div>> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a> <mailto:<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>><br>
<div class="im">> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> sr-dev mailing list<br>
</div>> <a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a> <mailto:<a href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>><br>
<div><div></div><div class="h5">> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</div></div></blockquote></div><br></div>