Subject: Messages with different types of transactions

From: "Bentov, Kohava" <[email-masked]>
Date: Wed, 20 Sep 2000 11:11:13 +0200

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]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 21 Sep 2000 09:57:47 -0400

Woops, too late in the day.  Yes, P4 has to be acted on
before S1 can be sent.  Sorry for creating confusion

Brian

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Thursday, September 21, 2000 9:49 AM
To: [email-masked]
Subject: Re: Messages with different types of transactions

"Rosen, Brian" wrote:
<snip>
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    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