7 Sep
2011
7 Sep
'11
12:43 p.m.
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-…
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
7 Sep
7 Sep
1:22 p.m.
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-…
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
1:40 p.m.
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
2:50 p.m.
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:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
15 Sep
15 Sep
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
16 Sep
16 Sep
2:42 p.m.
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.…
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(a)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(a)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(a)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(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
19 Sep
19 Sep
12:13 p.m.
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(a)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.…
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(a)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(a)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(a)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(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4800
days inactive
4812
days old
6 comments
4 participants
participants (4)
-
Jason Penton -
Jason Penton -
Richard Good -
Timo Reimann