[sr-dev] Dialog2
Richard Good
richgood2005 at gmail.com
Mon Sep 19 10:13:52 CEST 2011
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 at 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.html
>
> 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 at gmail.com
> > <mailto:jason.penton at 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 at 1und1.de
> > <mailto:timo.reimann at 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 at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
> >
> >
> >
> > _______________________________________________
> > sr-dev mailing list
> > sr-dev at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
> > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110919/02dd2bc8/attachment.htm>
More information about the sr-dev
mailing list