Subject: Re: Messages with different types of transactions

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 20 Sep 2000 08:41:06 -0400

The merged-01 text will become an RFC as soon as it works it's way up the
RFC editor's queue.  You can use the immediate ack response.

Regarding your second question:
1. Requests should be sent to where the other end wants them.  This is
determined from ServiceChange.  Your application must keep state associated
with ServiceChange to know where to send requests.

2. Replies MUST go back from whence they came.  It's not legal to have
requests
occur from arbitrary addresses and ports, but there are circumstances
(failover,
for example), where the protocol states that you must send responses back to
where they came from.  Here is an example.  Suppose you have a heavily
loaded network, and and the primary MGC sent three commands P1, P2 and P3.
It then decides it can't deal with this network, and uses an alternate.  The
way
it does so is to send a ServiceChange command.  Let's call this command P4.
Then it can send new commands over the Secondary MGC (which could be
another MGC, or another network interface on the same MGC).  Let's say that
the first command it sends is S1.

Now, the MG may get these commands out of order.  In fact, let's say that it
sees:
    P1
    P2
    P4
    S1
    P3

It must send the replies from P1-P4 back to the primary MGC, and the reply
to S1
back to the secondary MG.  I don't think there is any way around knowing
where
the command came from - you have to check the address each time.

Now, sharp observers may have noticed, as I just did, that we have a
problem.

Suppose what the MG observed is:
    P1
    P2
    P3
    S1
    P4

It gets a request from what it sees as an unknown MGC before it gets the
ServiceChange request.

So.........
I think we actually need to have some wording.

The MGC MUST get TransactionReply on the ServiceChange before it starts
sending commands from the secondary.  I'm not sure that this is really
ideal,
as ServiceChange indicates impending failure, and the MGC could fail between
the time it sends the ServiceChange and gets the response, but that's the
only
way I see it can work.

Brian

-----Original Message-----
From: Bentov, Kohava [mailto:[email-masked]]
Sent: Wednesday, September 20, 2000 5:11 AM
To: [email-masked]
Subject: Messages with different types of transactions

Hi all,

   Nowadays we are dealing with the transactionResponseAck issue.
 I have questions related to this issue.

FIRST QUESTION
How to handle differences between the 'draft-ietf-megaco-merged-01.txt'
document and  RFCs 2885 & 2886 ?

In the 'draft-ietf-megaco-merged-01.txt'  doc, there was an optional field
in the transactionReply that was called ImmAckRequiredToken.
This optional Token indicated when the sender of the reply needed immediate
ack.

-----------------------------
transactionReply = ReplyToken EQUAL TransactionID LBRKT
                                [ ImmAckRequiredToken COMMA]
                             ( errorDescriptor / actionReplyList) RBRKT
........
ImmAckRequiredToken = ("ImmAckRequired" / "IA")

-----------------------------
Our parser used  this Token (in our application) to identify when an
immediate
ack response was needed.

In RFC2885, this optional field disappeared and the Token was removed.
The modified declaration in the RFC is :
--------------------------------------------
transactionReply = ReplyToken EQUAL TransactionID LBRKT
                             ( errorDescriptor / actionReplyList) RBRKT
----------------------------------------------

In RFC2886, the following is written:

 " Resolution: add an optional field to TransactionReply allowing the
   responder to indicate if an immediate ACK is required.  Add text in
   the section indicating that when the responder has sent a provisional
   response, it shall also set the indicator in the final transaction
   reply to indicate that an immediate acknowledgement is required."

My question is:  Does it  mean that we can use the ImmAckRequiredToken
                          as was before ?
                          If not, what is the way to handle an indication of
immediate
                          ack according  to the "Resolution..."  paragraph ?

SECOND QUESTION
According to the protocol, a message can consist of different types of
transactions
( transactionRequest / transactionPending / transactionReply /
transactionResponseAck).
In paragraph 9 (TRANSPORT) the following is written:

"As described in section 7.2.8, either the MG or the MGC may supply an
address in the ServiceChangeAddress parameter to which subsequent
transaction requests must be addressed, but responses (including the
response to the initial ServiceChange request) must always be sent back to
the address which was the source of the corresponding request."

From this paragraph I understand that :
   1. The transactionRequest will be sent to the ServiceChangeAddress
parameter.
   2. The transactionReply and transactionPending will be sent to the
address
       of the corresponding request.
   3. The transactionResponseAck will be send to the address of the reply.
(it
       may be different from the address that the request was sent to -
ServiceChangeAddress).

My question is:  As far as I understand, If I don't want to check the
addresses each time
                          I send a messages (the addresses of each
transaction in the message),
                          I have to send messages of three types:
                              1. meggages of transactionRequests
                              2. meggages of transactionReplies &
transactionPendings
                              3. meggages of transactionResponseAck
                           Am I right ?

 Best regards,
    Kohava Bentov
    SW Development
    TELRAD Networks
     mail: [email-masked] <mailto:[email-masked]>

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 21 Sep 2000 09:49:21 -0400

"Rosen, Brian" wrote:

<snip>

> problem.Suppose what the MG observed is:    P1    P2    P3    S1
> P4It gets a request from what it sees as an unknown MGC before it gets
> the ServiceChange request.So.........I think we actually need to have
> some wording.The MGC MUST get TransactionReply on the ServiceChange
> before it startssending commands from the secondary.  I'm not sure
> that this is really ideal,as ServiceChange indicates impending
> failure, and the MGC could fail betweenthe time it sends the
> ServiceChange and gets the response, but that's the onlyway I see it
> can work.Brian
>
>
> FSA: Actually, I don't see the problem. If the MGC wants to redirect
> the MG it sends a ServiceChange(Handoff) to the MG. The MG in turn
> MUST  establish a new control association with the secondary MGC
> before that MGC can send any messages to it. Thus S1 and P4 cannot
> arrive out of order.
>
> -- Flemming
>

<snip>

--
Flemming Andreasen
Cisco Systems