< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

RE: [reSIProcate] DUM state machine


Well, simply put, the ACK is the ONLY indication to the UAS that the
requested media session is successfully connected on both sides.

Specifically, the ACK indicates to the UAS that the UAC has received the
answer; and only upon receiving the answer can the UAC transmit media to
the UAS (since the UAS receive media ports are contained in the answer).
Note that the significance of the ACK becomes greater in a lossy network
since the 200 may be dropped one or more times, potentially causing a
significant delay in the ability of the UAC to transmit media to the
UAS.

In some applications (especially for automated media servers, etc.), the
presence of a bidirectional media path is a critical thing to know.

Take for example the following situation where Alice calls her bank's
automated status line. The bank system answers and the IVR system speaks
"Enter account number". Alice hears this and speaks/keys her account
number. BUT, since the answer hasn't been received by Alice's UAC, there
is no media path from Alice to the Bank yet, so her account number is
either not heard or (more likely) truncated. If, however, the bank waits
til the ACK is received to speak, everybody would live happily ever
after :-)

               Alice                            Bank
                 |                               |
                 |---------- INVITE ------------>|
                 |                               |
                 |<----------  180 --------------|
                 |                               | <-- Bank answers,
                 |   drop<---  200 --------------|     "Enter acct #"
Alice enters --> |                     (T1)      |
    acct #       |   drop<---  200 --------------|
                 |                    (2*T1)     |
                 |   drop<---  200 --------------|   (3.5 sec delay)
                 |                    (4*T1)     |
                 |<----------  200 --------------|
                 |                               |
                 |-----------  ACK ------------->|
                 |                               | <-- Bank SHOULD
                 |                               |     speak here

Now granted, this is a hypothetical situation just to illustrate the
point; you can play with timings however you want, but there still
exists a window that you can't close easily without the ACK
notification.

To generalize the point, I would say that *any* SIP stack that might be
used in an automated application should make use of the
"OnConnectedConfirmed" callback.

   - joe


-----Original Message-----
From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On Behalf
Of Jason Fischl
Sent: Sunday, November 20, 2005 12:34 PM
To: Scott Godin
Cc: Derek MacDonald; Joe Boucher; Francesco Fondelli;
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] DUM state machine

I'm still not clear on why anybody cares when the ACK is received. The
only case where the ACK is relevant to the application is where the
answer is carried in the ACK and in this case onAnswer will be called.

On 11/18/05, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> Sticking with the "no changes to current apps" philosophy.
Considering
> that onAckReceived doesn't really make sense - since this would not be
> called in the case when the ACK carries an answer - and could be
> misleading.   I vote for onConnectedConfirmed - seems to make more
sense
> to me then onConnectReturn.  : )
>
> Scott
>
> > -----Original Message-----
> > From: Derek MacDonald [mailto:derek@xxxxxxxxxxxxxxx]
> > Sent: Friday, November 18, 2005 12:10 AM
> > To: 'Joe Boucher'; Scott Godin; 'Francesco Fondelli'
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: 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
> > >
> >
> >
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>