Subject: Re: Comments on draft-ietf-megaco-protocol-07

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 16 Mar 2000 05:25:23 -0500

Responses couple of open items from your original note.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Friday, March 10, 2000 7:10 PM
> > > 24) D.1.4, last paragraph specifies that "Upon receipt of of a final
> > > response, an immediate confirmation shall be sent, and normal
> repetition
> > > timers shall be used thereafter", however it is not specified how the
> > > entity determines whether the final response needs to be confirmed
> > > immediately or not (consider the case where the pending was lost). A
> > > specification for this needs to be added.
>
> Didn't see a response here.
        [[TomT]]
        Agreed that the behaviour of an MGC that receives a Transaction
Pending may differ from that of an MGC which does not when the final
response comes, but any possible tightening of the conditions for immediate
acknowledgement of final responses (e.g.  do it whenever the original
transaction has been sent more than once) is just a bit of optimization.  It
potentially generates an extra message from the MGC to prevent an extra
final Transaction Response from the MG.

> >
> > >
> > > 25) D.1.5, last paragraph specifies that "When the MG establishes a
> new
> > > control association, it can retransmit to the new MGC. Alternatively,
> a
> > > MG may use a ServiceChange with ServiceChangeMethod equal to
> > > disconnected to inform the new MGC that the MG lost one or more
> > > transaction". In order to prevent duplicate transactions, it must be
> > > required that transactions cannot be retransmitted T-MAX time after
> > > their initial transmission. Consequently, a disconnected ServiceChange
> > > *must* be issued in such cases.
>
> Didn't see a response here.
        [[TomT]]
        There is a problem with this paragraph -- "establishes a new control
association" hides detail that should have been spelled out.
        That detail is which ServiceChangeMethod to use in the process.  And
as you say, that must be "Disconnected".

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 16 Mar 2000 16:05:04 -0800

Tom-PT Taylor wrote:

>      Pending may differ from that of an MGC which does not when the
>      final response comes, but any possible tightening of the
>      conditions for immediate acknowledgement of final responses
>      (e.g.  do it whenever the original transaction has been sent more
>      than once) is just a bit of optimization.  It potentially
>      generates an extra message from the MGC to prevent an extra final
>      Transaction Response from the MG.
>
It's actually worse than that. Since the transaction initiator *shall*
confirm this final response, consider what happens if the pending got
lost, and the final did not. The transaction initiator has no idea that
it's supposed to confirm this message, however the responder, expecting
a confirmation it will never get will be resending this final response
until it eventually gives up and probably concludes that something's
wrong. What you need is some kind of indication in the final response
instructing the receiver that it *must* confirm this response.

>
>
>      >
>      > >
>      > > 25) D.1.5, last paragraph specifies that "When the MG
>      establishes a new
>      > > control association, it can retransmit to the new MGC.
>      Alternatively, a
>      There is a problem with this paragraph -- "establishes a new
>      control association" hides detail that should have been spelled
>      out.
>
>      That detail is which ServiceChangeMethod to use in the process.
>      And as you say, that must be "Disconnected".
>

-- Flemming