Subject: Re: TransactionPending message flow

From: Brian Rosen <[email-masked]>
Date: Thu, 28 Oct 1999 12:59:11 -0400

While I think there is no harm in sending pending as you suggest,
it is not necessary, as the timeout value of the repeated command
would be greater than the first command's pending timeout
    First Req Send
                     First Req Recieve
                       <timeout>
                     First Pend Send  (lost)
    <timeout>
    Second Req Send
                     Second Req Recv (ignore)
                       <timeout from First Req Recv>
                           Second Pend Send
    Second Pend Recv
                       <timeout from Second Req Recv>
                     Send Ack
    Ack Recv

Brian
> -----Original Message-----
> From: Harpreet Singh Anand [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 1:12 AM
> To: [email-masked]
> Subject: Re: TransactionPending message flow
>
>
> Hello Brian,
>
> TransactionPending should also be sent in the case of MGW
> receiving the same
> command again. Consider the following flow:
>
> 1. Message Request X goes from MGW to GW
> 2. The GW sends TransactionPending Message to MGW
> 3. The TransactionPending Message gets lost OR reaches after
> MGW has already
> timed out for the response.
> 4. The MGW resends Message Request X to GW
>     (MGW times out waiting for Response)
> 5. The GW sends TransactionPending to MGW
> 6. The GW (finally) sends Reply to MGW.
>
> Please comment.
>
> Regards,
> Harpreet
>
>
>
> Brian Rosen wrote:
>
> > Flow A
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Tim Vetter [mailto:[email-masked]]
> > > Sent: Wednesday, October 27, 1999 7:27 PM
> > > To: [email-masked]
> > > Subject: TransactionPending message flow
> > >
> > >
> > > What the TransactionPending message communication
> > > look like?  Does it look like flow A or B?
> > >
> > > Flow A (Seems indicated by Section 8.2.3):
> > > 1. Message Request X goes from MGW to GW
> > > 2. The GW sends TransactionPending Message to MGW
> > > 3. The GW sends TransactionPending Message to MGW
> > > 4. The GW (finally) sends Reply to MGW.
> > >
> > > Flow B (Seems indicated by Section E.4):
> > > 1. Message Request X goes from MGW to GW
> > > 2. The MGW resends Message Request X to GW
> > >    (MGW times out waiting for Response)
> > > 3. The GW sends TransactionPending to MGW
> > > 4. The MGW resends Message Request X to GW
> > >    (MGW times out waiting for Response)
> > > 5. The GW sends TransactionPending to MGW
> > > 6. The GW (finally) sends Reply to MGW.
> > >
> > > What triggers the Transaction Pending in GW?  Is it
> > > timer in GW, or is it receiving the same command again
> > > from the MGW?
> > >
>
> --
>
> Regards,
> Harpreet
>
> _________________________________
> Harpreet Singh Anand
> Ficon Technology
> E-mail :  mailto:[email-masked]
> Web    :  http://www.ficon-tech.com
>

---

From: Al Varney <[email-masked]>
Date: Fri, 29 Oct 1999 09:40:16 -0500

>                       <timeout from Second Req Recv>

   The "<timeout from Second Req Recv>" bothers me -- why would one start
a timer for an (ignore)d Req?  Doesn't the example work without this line?

   I think the point you were making was that PEND is not considered a true
RESPONSE to the First Req, and so it is not sent as part of the Annex E
procedure for responding to repeated commands.  In this model, PEND is
only sent because the timer (normalMGExecutionTime) expires.  (Section 8.2.3)

   As Harpreet & Tim Vetter noted, this model clearly disagrees with E.4:
    "Entities that can predict that a transaction will require a long
     execution time may send a provisional response, “Transaction Pending”.
     They should send this response if they receive a repetition of a
     transaction that is still being executed."

   Both mechanisms can co-exist, but would seem to be overkill.  In fact,
Annex E is a pretty confusing read -- the whole thing seemed so much clearer
when Christian was arguing for it (on the MGCP list?).  Maybe it's just me....

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]