RE: [reSIProcate] DUM state machine
onConnectReturn with a default do nothing implementation would be my choice
because it would not affect existing application built on top of DUM.
--Derek
> -----Original Message-----
> From: Joe Boucher [mailto:jboucher@xxxxxxxxxxxxx]
> Sent: Thursday, November 17, 2005 8:14 PM
> To: Derek MacDonald; Scott Godin; Francesco Fondelli
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] DUM state machine
>
> Derek, you have a good point.
>
> From section 5.1 in 3264:
> Once the offerer has sent the offer, ... it MUST be prepared
> to send and receive media for any sendrecv streams in the offer ...
>
> So a UAS who waits to receive the 200 before cutting through the media
> is technically in violation of 3264. However, I have worked with several
> PSTN gateways that don't cut the TDM circuit through until the 200
> arrives
> (early media aside).
>
> Regardless, I really think two callbacks are needed. One when the 200 is
> sent, and one when the ACK is received. Call them onConnected() and
> onConnectConfirm() if you like (or whatever makes sense).
>
> Then the app can decide what it does when...
>
> - joe
>
>
> -----Original Message-----
> From: Derek MacDonald [mailto:derek@xxxxxxxxxxxxxxx]
> Sent: Thursday, November 17, 2005 4:31 PM
> To: 'Scott Godin'; 'Francesco Fondelli'; Joe Boucher
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [reSIProcate] DUM state machine
>
> Here is a reason that onConnected is called when a 200 is received:
>
> Alice calls Bob:
>
> Alice Bob
> |
> |---------- INVITE ------------>|
> | |
> |<---------- 180 --------------|
> | | <-- Bob Picks Up
> |<---------- 200 --------------|
> | |
>
> As soon as Bob picks up the phone the 200 can be sent. Bob is likely to
> say
> hello as soon as he picks up the phone. Since media is being sent, the
> connected state makes sense. User Agents that don't receive media until
> the
> 200 is receive are unlikely to interact well with phone style endpoints.
> I
> believe they also might be violating 3264.
>
> --Derek
>
> -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-
> > devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Godin
> > Sent: Thursday, November 17, 2005 5:19 AM
> > To: Francesco Fondelli; Joe Boucher
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] DUM state machine
> >
> > I kind of like this proposal too - it offers more flexibility. But
> > changing the callbacks now - would effect any current applications.
> It
> > wouldn't be too hard for me to fix up my app.
> >
> > I would like to hear from the other core DUM designers on this one.
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Francesco Fondelli [mailto:francesco.fondelli@xxxxxxxxx]
> > > Sent: Thursday, November 17, 2005 6:35 AM
> > > To: Joe Boucher
> > > Cc: Scott Godin; Steve Robichaud;
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > > Subject: Re: [reSIProcate] DUM state machine
> > >
> > > On 11/16/05, Joe Boucher <jboucher@xxxxxxxxxxxxx> wrote:
> > > [cut]
> > > > I'd say the proper mode of callback behavior would be:
> > > > - Calling onAccepted() when the 200 is sent
> > > > - Calling onConnected when the ACK is received
> > >
> > >
> > > I'd *really* like this behavior. Actually I have to use tricks using
> > > timers to
> > > proper mark a call as started (from a billing point of view) because
> > there
> > > is
> > > no indication of "onAckReceived". To have onConnected() called when
> > the
> > > ACK
> > > is received would be great.
> > >
> > > my 2 cent
> > > Ciao
> > > FF
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>