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