Hi All,
Does anyone know if work has been started on dialog2 as proposed here: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
If not we are looking at starting it if that is ok? Also, who wrote this page on the wiki?
I know some features like spiraling have been included in original dialog module, but I know forking doesn't work and terminating early dialog sessions, etc
Cheers Jason
Hey Jason,
On 07.09.2011 10:43, Jason Penton wrote:
Does anyone know if work has been started on dialog2 as proposed here: http://www.kamailio.org/dokuwiki/doku.php/modules-new-design:dialog-module-d...
If not we are looking at starting it if that is ok?
Absolutely from my point of view.
Also, who wrote this page on the wiki?
Mostly Iñaki and myself. We've never had the opportunity to get things started, however, so I'd be glad for your effort. If you wish to dive into the gory historical details preceding the creation of the design document, there's a rather extensive thread on the mailing list too.
I know some features like spiraling have been included in original dialog module, but I know forking doesn't work and terminating early dialog sessions, etc
Right, spiraling support has been added by me a while ago, including the callback DLGCB_SPIRALED mentioned on the wiki page. Apart from that, pretty much nothing specified has been implemented yet so feel free to take a stab.
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.
Cheers,
--Timo
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
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.
--Timo
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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.dewrote:
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 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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
-
Jason Penton -
Jason Penton -
Richard Good -
Timo Reimann