15 Sep
2011
15 Sep
'11
6:33 p.m.
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(a)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(a)1und1.de>wrote;wrote:
On 07.09.2011 11:22, Timo Reimann wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev