[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