[sr-dev] Dialog2

[Timo Reimann]

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