Subject: Re: Washington Issue 13 - Receipt of Duplicate Request when Pendi ng

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 1999 10:44:28 -0500

It simply keeps a copy of the reply.  It DOES NOT rerun the
transaction.

If UDP/ALF is the transport, you keep them until you get
the TransactionAck

If TCP is the transport, you probably keep them for something
longer than the TCP timeout (someone have a more precise
idea?)

Brian

> -----Original Message-----
> From: Paul Hollis [mailto:[email-masked]]
> Sent: Tuesday, November 16, 1999 10:16 AM
> To: Brian Rosen
> Cc: [email-masked]
> Subject: Re: Washington Issue 13 - Receipt of Duplicate Request when
> Pending
>
>
> Hi Brian,
>
> does this mean the MG would execute the transaction again, or
> does the MG need some sort of memory of recent replies sent?
>
> Even if the MG were to discard it, the MG would need to have some
> memory of previous transactions, to know that this transaction
> had already been executed. Perhaps the MG has a certain time
> period for which it remembers recent transactions, after which
> it assumes the transaction is a new/different one and it can
> execute it.
>
> Regards Paul.
>
> Regards Paul.
>
> Brian Rosen wrote:
>
> > I think that a duplicate request after sending a reply
> > could mean the reply was lost.  The responder should repeat
> > the reply.  Of course it could be that the duplicate request
> > and the reply passed in the night, but sending a duplicate
> > reply would not hurt.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Paul Hollis [mailto:[email-masked]]
> > > Sent: Tuesday, November 16, 1999 9:07 AM
> > > To: Brian Rosen; MEGACO Mailing list
> > > Subject: Re: Washington Issue 13 - Receipt of Duplicate
> Request when
> > > Pending
> > >
> > >
> > > Hi Brian,
> > >
> > > Along a similar line:-
> > >
> > > what happens if a MG sends a REPLY to a transaction and then gets
> > > a REQUEST with the same Transaction ID. Does it treat
> this as a new
> > > transaction and service it or does it assume that it is a
> > > repeat of the
> > > original one and discard it (ie. the MGC resent the
> transaction just
> > > as the MG was sending the reply)?
> > >
> > > Regards Paul.
> > >
> > >
> > > Brian Rosen wrote:
> > >
> > > > A number of issues were raised in the Washington meeting that
> > > > were "send to the list".  This is one of these issues, with the
> > > > problem and my suggested fix.
> > > >
> > > > Problem:
> > > > What should the initiator do when it has sent a "pending"
> > > > response, but receives a duplicate request.  Possible answers
> > > > are: send another pending immediately, or wait for the normal
> > > > timeout and send pending.
> > > >
> > > > Proposed Solution
> > > > Since the timeout of the original pending must be less than
> > > > the timeout of the duplicate, the responder will see
> > > > the 2nd pending response within it's timeout window.  Therefore,
> > > > it is not necessary to respond with an extra pending.
> > > >
> > > > It should be noted that there is no harm in sending extra pends.
> > > >
> > > > Also note that if the responder finishes within the timeout
> > > > of the first pend, sending the ack (or error) will satisfy
> > > > the original request and the duplicate.
> > > >
> > > > Brian
> > >
> > > --
> > >
> > > oooooooooooooooooooooooooooooooooooooooooooooo
> > >   Paul Hollis
> > >   Ericsson Eurolab Deutschland GmbH
> > >   Ericsson Allee 1
> > >   D-52134 Herzogenrath
> > >   Germany
> > >   Phone: +49 2407 575 8092
> > >   email: [email-masked]
> > > oooooooooooooooooooooooooooooooooooooooooooooo
> > >
> > >
>
> --
>
> oooooooooooooooooooooooooooooooooooooooooooooo
>   Paul Hollis
>   Ericsson Eurolab Deutschland GmbH
>   Ericsson Allee 1
>   D-52134 Herzogenrath
>   Germany
>   Phone: +49 2407 575 8092
>   email: [email-masked]
> oooooooooooooooooooooooooooooooooooooooooooooo
>
>

---

From: Paul Hollis <[email-masked]>
Date: Wed, 17 Nov 1999 09:01:18 +0100

Hi Brian,

don't we want H.248 to be independent of the underlying transport?
Therefore, we would probably want a timer in the protocol, perhaps
set to similar values as the underlying transaport timers, but still
independent.

What if we were to just store a copy of the transaction IDs for this certain

period, and if a transaction comes in with a transaction ID that we have
stored
then we just discard it. I would assume the MGC would end up resending the
request
again if it needed to. Whereas if it was a case where the REPLY and the
re-REQUEST "passed in the night" the MG would have got the reply and no
re-REQUEST is needed.

Once the period expires then transaction should be treated as new
transactions
and be serviced as normal.

Your thoughts?

Regards Paul.

--