Subject: How does the MGC rebuild a long transaction in ALF/UDP

From: Susumu YAMAMOTO <[email-masked]>
Date: Wed, 21 Mar 2001 17:25:10 +0900

Hi all,

I have a question about ALF/UDP in Annex D.1 of the H.248.
(I think that ALF stands for Application Level Framing.)

If an MG has a transaction which is longer than 64KB to send over
UDP/IP, the MG must divide the transaction to some pieces each
of which is shorter than 64KB and send them by other message each
other.

In this case, each message contains the transactions which is
specified with the same transactionID but differs in contents.

But we have no parameter to specify the total length of the
transactions or the total length of the messages.

How does the MGC rebuild the original transaction?

I think an MG may have a longer transaction than 64KB  to send as a
transaction reply in the wildcard situation.

Regards,

Sususmu

-*-*-*
SUSUMU YAMAMOTO
NTT Network Service Systems Laboratories
mailto: [email-masked]
TEL:+81 422 59 2744  ISDN-FAX:+81 422 37 7467

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 21 Mar 2001 11:29:56 -0500

Probably, you would be advised to break the transaction into
multiple smaller transaction, and use the identified mechanisms
to enforce sequential execution of these smaller transactions.

Brian

> -----Original Message-----
> From: Susumu YAMAMOTO [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2001 3:25 AM
> To: [email-masked]
> Subject: How does the MGC rebuild a long transaction in ALF/UDP
> 
> 
> Hi all,
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 21 Mar 2001 11:44:46 -0500

The short answer is that we have not specified this.  If it is a real issue
we may have to consider it, but our attention so far has been on ways to cut
down the size of the audit response.

---

From: Susumu YAMAMOTO <[email-masked]>
Date: Thu, 22 Mar 2001 16:58:33 +0900

Dear Brian,

Thank you for your suggestion.

What is the identified mechanisms you mentioned below?
Please tell me where it is described in H.248/MEGACO.

When one transaction would be broken into multiple small transactions,
what is the transaction ID of each transactions?
I think that all small transactions should have the same transaction ID
and an MG must show an MGC that multiple transactions must be rebuilt
to one transaction.
I do not understand the way to relate transactions.

Is my idea wrong?

Regards,

Susumu

---

-*-*-*
SUSUMU YAMAMOTO

---

From: Susumu YAMAMOTO <[email-masked]>
Date: Tue, 27 Mar 2001 12:31:12 +0900

Hi all,

I think the error code would be a good solution without changing
the present standard too.

But in the case of TCP as transport, you also have the restriction
of the message length to 64KB because of TPKT(RFC1006).

I believe that MEGACO should have a mechanism for ALF essentially
as well as SIP does.

By the way, what did the authors think at first about the mechanism
for ALF in the sentence quoted from D.1 below?

"Implementators using IP/UDP with ALF should be aware of the
  restrictions of the MTU on the maximum message size."

Regards,

Susumu

---
>I think the error code would be a good idea.
>
> > From: Christer Holmberg 
> [<mailto:[email-masked]>mailto:[email-masked] 
> icsson.se]
> > Sent: Saturday, March 24, 2001 2:26 PM
> > To: Taylor, Tom-PT [NORSE:B881:EXCH]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: How does the MGC rebuild a long transaction in ALF/UDP
> >
> >
> >
> > Hi,
> >
> > >I agree that the use of TCP for audits is the sensible solution, but
> > >it does mean that the MG has to support TCP and also that if UDP is
> > >subsequently desired a new association has to be set up.  Since the
> > >transport is controlled by the MG rather than the MGC this may be a
> > >bit difficult to achieve.
> > >
> > >The only practical solution according to the present standard is for
> > >the MGC to restrict the number of terminations covered by any one
> > >audit query.
> >
> > What about having an error code indicating that the wildcard can't be
> > used, since the reply would be too big? The MGC can then
> > choose to split
> > up the Audit in multiple requests.
> >
> > And, if the MG is really smart, it could perhaps also tell
> > the MGC what
> > kind of wildcard value would be suitable for the requested information
> > for this specific Audit. This feature should be optional, however, I
> > think.
> >
> >
> > Regards,
> >
> > Christer Holmberg
> > Ericsson Finland
> >
> >
> >
> >
> >
> > >
> > > > From: Christer Holmberg 
> [<mailto:[email-masked]>mailto:[email-masked] 
> icsson.se]
> > > > Sent: Friday, March 23, 2001 1:32 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]
> > > > Subject: Re: How does the MGC rebuild a long transaction
> > in ALF/UDP
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > >Hi all,
> > > > >
> > > > >As Chakravarthi said, I meant the case that transaction REPLY
> > > > >is longer than 64KB.
> > > > >
> > > > >Transaction REPLY from MG may be longer than 64KB, if MGC
> > > > >send the "Audit" transaction REQUEST which is specified with
> > > > >wildcard "ALL".
> > > > >
> > > > >In this case, transaction ID has defined with transaction REQUEST
> > > > >in MGC and the related transaction REPLYs (if we must brake it
> > > > >into some multiple transactions) from MG must use the same
> > > > >transaction ID, I think.
> > > >
> > > > I was talking about the REPLY :) Maybe I used the word "response"
> > > > sometime, but I meant the same...
> > > >
> > > > >Probably many implementations will adopt UDP as transport and
> > > > >the number of terminations in MGs like trunking GWs apts to
> > > > >increase recently.
> > > > >
> > > > >If an MG has 2,000 (it may have a interface of STM-1) of physical
> > > > >terminations, only 32B are allowed for one termination
> > to restrict
> > > > >the total size of transaction REPLY to less than 64KB.
> > > >
> > > > I DO agree that it is a problem, but my mail was more about
> > > > if we should
> > > > try to solve it on the application level, or simply use another
> > > > transport protocol.
> > > >
> > > > >We should not have such a restrictions in the case of UDP.
> > > >
> > > > One option could be to use TCP for Audits, while you still use UDP
> > > for
> > > > other commands. After all, you're not going to send that many
> > > Audits,
> > > > and probably not at the same time if you use wildcarding,
> > so I don't
> > >
> > > > think that using TCP would be a problem from that point of view.
> > > >
> > > > >As Christer pointed out, we can solve this by adding two
> > > > fragmentation
> > > > >headers(*) with transaction REPLY as option in the case of UDP
> > > below.
> > > > >
> > > > >    TransactionReply ::= SEQUENCE
> > > > >    {
> > > > >       transactionId
> > > > >     *total number of the transactions with the same Id
> > > > >     *sequence of the transaction with the same Id
> > > > >       immAckRequired
> > > > >       transactionResult
> > > > >       {  ... }
> > > > >    }
> > > > >
> > > >
> > > > The problem with this solution is that you have to know how many
> > > > fragments you will have before you can start sending the
> > > > reply messages,
> > > > ie you must first collect the information from all your
> > thousands of
> > >
> > > > terminations, then calculate how many messages are needed to send
> > > the
> > > > information, and then start to send the fragments.
> > > >
> > > > In this case, I THINK using pending (provisional)
> > response messages
> > > > would be better - and faster. You send the information as you get
> > > it,
> > > > and when you don't have anymore to send you send your final REPLY.
> > > >
> > > > I know that none of the proposals above (except for the option to
> > > use
> > > > TCP for Audits only) are acording to the current
> > standard. But, like
> > > I
> > > > said earlier, I think that application level fragmentation is not
> > > > supported by the current standard, so if we want to support this
> > > > something has to be done.
> > > >
> > > > >Any ideas do you have?
> > > >
> > > > I think that the easiest (maybe NOT the best) solution would be to
> > > use
> > > > TCP for Audits, because that would not affect the current
> > standard.
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Christer Holmberg
> > > > Ericsson Finland
> > > >
> > > > >
> > > > > Regards,
> > > > >
> > > > > Susumu
> > > > >
> > > > > ---
> > > > > >Hi,
> > > > > >
> > > > > >I will give a few comments on this, since a similar issue
> > > > also exists
> > > > > >for SIP.
> > > > > >
> > > > > >So, that fact is that UDP has some restrictions. Now, there are
> > > two
> > > > > >options:
> > > > > >
> > > > > >1. You try solve this on the application level (in this case in
> > > the
> > > > > >H.248 protocol), for example by adding fragmentation
> > > > headers, or maybe
> > > > > >by having some kind of "fragmentation package"... or something
> > > > > >similar...
> > > > > >
> > > > > >2. You accept the limitations you have by using UDP as
> > transport
> > > > > >protocol, and if you can't live with that you use TCP or
> > > > SCTP (I guess
> > > > > >this is one of the few advantages of defining multiple
> > transport
> > > > > >protocols for H.248 in the first place :)...
> > > > > >
> > > > > >
> > > > > >Maybe I'm wrong, but I don't see any solution for 1)
> > in the core
> > > > > >protocol, so I guess you would have to define some kind of
> > > > package - if
> > > > > >it would even work then.
> > > > > >
> > > > > >...or, you use 2).
> > > > > >
> > > > > >Also, you could maybe send multiple provisional reply
> > > > messages, each
> > > > > >containing parts of the response, and the final reply
> > > > message would then
> > > > > >indicate that the whole response has arrived. But, I don't
> > > > know how well
> > > > > >that would work either, and/or if it also requires some
> > > extensions
> > > > > >(packages, etc.)
> > > > > >
> > > > > >
> > > > > >Regards,
> > > > > >
> > > > > >Christer Holmberg
> > > > > >Ericsson Finland
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >"P.S.K. Chakravarthi" wrote:
> > > > > > >
> > > > > > > Brian,
> > > > > > >
> > > > > > > In case of a transaction you are correct.  But how
> > > > Reply can be split.  In
> > > > > > > case of Audit, Audit reply may cross 64k.  This can not
> > > > be sent using 2
> > > > > > > transaction Ids, because MGC can not expect Reply in a
> > > un-known
> > > > > > > transaction Id.
> > > > > > >
> > > > > > > thanks
> > > > > > > Chak
> > > > > > >
> > > > > > >   ALCATEL, USA Inc.                      Email:
> > > > > > [email-masked]
> > > > > > >   1000 Coit Road Plano, Texas 75075
> > > > > > >   ******** The opinions expressed are not those of Alcatel
> > > USA,
> > > > > > Inc.********
> > > > > > >
> > > > > > > On Thu, 22 Mar 2001, Rosen, Brian wrote:
> > > > > > >
> > > > > > > > Section 9.1 details how you enforce ordering of
> > > > commands across
> > > > > > > > transactions.
> > > > > > > >
> > > > > > > > Each transaction MUST be different (unique) TransactionId.
> > > > > > > > Therefore, if you break up a transaction into multiple
> > > smaller
> > > > > > > > transactions, each smaller part will have a different
> > > > transactionId.
> > > > > > > > The reciever doesn't need to know that the
> > > > transactions are related.
> > > > > > > > The sender can track this with internal state if it needs
> > > to.
> > > > > > > >
> > > > > > > > Brian
> > > > > > > >
> > > > > > > > > From: Susumu YAMAMOTO
> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > > > > > > Sent: Thursday, March 22, 2001 2:59 AM
> > > > > > > > > To: [email-masked]
> > > > > > > > > Subject: RE: How does the MGC rebuild a long
> > > > transaction in ALF/UDP
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Dear Brian,
> > > > > > > > >
> > > > > > > > > > > From: Susumu YAMAMOTO
> [<mailto:[email-masked]>mailto:[email-masked]]
> > > > > > > > > > > I think an MG may have a longer transaction
> > > > than 64KB  to
> > > > > > > > > send as a

-*-*-*
SUSUMU YAMAMOTO

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Tue, 27 Mar 2001 10:57:46 +0200

I propose the following wording taking into account Christers comment.

2.58 Error Code # : 534 Name: Message exceeds maximum transport PDU size
Definition: The MG or MGC is unable to assemble a message due to that
the number of bytes for the message exceeds the underlying transport's
maximum protocol data unit size. The command causing the exceed of message length
is not carried out.  

Package: -
Reference: For the handling of the other commands in the transaction see chapter 8.

Alf
-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: den 27 mars 2001 08:00
To: Tom-PT Taylor
Cc: 'Christer Holmberg'; [email-masked]; [email-masked];
Alf Heidermark

G'Day Tom, all,

A suggestion - do we agree to add the following to the H.248 Annex L -
Error Code and Service Change Reasons:

2.58 Error Code # : 534 Name: Message exceeds maximum transport PDU size
Definition: The MG or MGC is unable to assemble a message due to that
the number of bytes for the message exceeds the underlying transport's
maximum protocol data unit size. The actions included in the transaction
request are not carried out. If the request contained wildcarded a
transaction ID the MGC or MG should resend the request with a smaller
subset of termination Ids.
Package: -
Reference: No
Error Text in the error Descriptor: NA
Comment: -

Cheers, Christian

Tom-PT Taylor wrote:
> > From: Christer Holmberg [mailto:[email-masked]]
> [mailto:[email-masked]]
> > > [mailto:[email-masked]]
> > > > > > > > > I think that all small transactions should have the
> same
> > > > > > > > > transaction ID
> > > > [mailto:[email-masked]]

---

From: Dave Sclarsky <[email-masked]>
Date: Tue, 27 Mar 2001 11:13:07 -0500

Tom,
 
I also have a problem with roll back, but not just for the whole
transaction!  I'm not sure how an MG or MGC 'application' can know when to
stop building a reply message.  The details of how big a PDU can be and what
the transport limitations are should be (imho) hidden well below the command
processing logic.  Maybe this is an implementation issue, but our 'protocol
stack' builds the PDUs from generic binary data structures that are built by
the 'application'.  The application has no idea if the transport is UDP or
TCP or SCTP.  Nor does the application know if the encoding is binary, short
text or long text. Therefore, when the application processes a wildcard
command, how can it know when to stop? 
 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 9:05 AM
To: 'Christian Groves'
Cc: 'Christer Holmberg'; [email-masked]; [email-masked]; Alf
Heidermark
Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

First comment: I think this error should only affect responses -- can't see
an entity reporting an error because it couldn't formulate a request.

Second comment: the idea that the transaction is rolled back bothers me.
This is easy enough for audits, not so easy for anything else.  I'd suggest
our usual approach: the command which caused the PDU overflow is rolled
back, but any commands which preceded it remain in place.  Remember that
wildcarding creates a long series of individual commands.

As a result, I'd suggest the following wording: 

2.58 Error Code # : 534 Name: Response exceeds maximum transport PDU size 

Definition: The MG or MGC is unable to assemble a complete transaction
response because the number of bytes for the message would exceed the
maximum protocol data unit size of the underlying transport.  The command
instance the response to which would have caused the overflow is treated as
if it were in error, and the remainder of the transaction is not executed.
Note that this situation will typically arise in conjunction with the use of
wildcarding, which causes the original command to be expanded into a series
of similar command instances.

Implementer's note: detection of PDU overflow must occur at a point where
there is still room in the PDU for the error descriptor.

Package: - 
Reference: No 

> From: Christian Groves [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Tuesday, March 27, 2001 1:00 AM 
> > > From: Christer Holmberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > > I think that the easiest (maybe NOT the best) 
> solution would be 
> > to 
> > > > use 
> > > > > > >1. You try solve this on the application level (in 
> this case 
> > in 
> > > > the 
> > > > [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > > > [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 27 Mar 2001 12:15:53 -0500

Yes, that would be consistent with normal H.248 behaviour.

-----Original Message-----
From: Chuong Nguyen [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 10:47 AM
To: megaco
Subject: Re: How does the MGC rebuild a long transaction in ALF/UDP

Tom 

For the wildcarded command case, said if the wildcarded command expands into

100 command replies.  There is even room for 50 of the commands. 
Should 50 command replies be returned and for the 51st command an error
returned 
or the wildcarded command should result in an error? 

Thanks 
Chuong 

Tom-PT Taylor wrote: 

Package: - 
Reference: No 

-- 

  Alcatel USA, Inc             Internet: [email-masked]

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Wed, 28 Mar 2001 09:14:24 +0200

It would have been good if the application (H.248 ) is aware of the transport. However, as the spec is done H.248 does not work in the same way. It depends on the underlaying transport. See Annex d, H and I. The dependency comes from that the ubnderlaying transport offeres different service.

-----Original Message-----
From: Dave Sclarsky [mailto:[email-masked]]
Sent: den 27 mars 2001 18:13
To: 'Tom-PT Taylor'; 'Christian Groves'
Cc: 'Christer Holmberg'; [email-masked]; [email-masked]; Alf Heidermark
Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

Tom,
 
I also have a problem with roll back, but not just for the whole transaction!  I'm not sure how an MG or MGC 'application' can know when to stop building a reply message.  The details of how big a PDU can be and what the transport limitations are should be (imho) hidden well below the command processing logic.  Maybe this is an implementation issue, but our 'protocol stack' builds the PDUs from generic binary data structures that are built by the 'application'.  The application has no idea if the transport is UDP or TCP or SCTP.  Nor does the application know if the encoding is binary, short text or long text. Therefore, when the application processes a wildcard command, how can it know when to stop? 
 
DaveS.

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, March 27, 2001 9:05 AM
To: 'Christian Groves'
Cc: 'Christer Holmberg'; [email-masked]; [email-masked]; Alf Heidermark
Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

First comment: I think this error should only affect responses -- can't see an entity reporting an error because it couldn't formulate a request.

Second comment: the idea that the transaction is rolled back bothers me.  This is easy enough for audits, not so easy for anything else.  I'd suggest our usual approach: the command which caused the PDU overflow is rolled back, but any commands which preceded it remain in place.  Remember that wildcarding creates a long series of individual commands.

Definition: The MG or MGC is unable to assemble a complete transaction response because the number of bytes for the message would exceed the maximum protocol data unit size of the underlying transport.  The command instance the response to which would have caused the overflow is treated as if it were in error, and the remainder of the transaction is not executed.  Note that this situation will typically arise in conjunction with the use of wildcarding, which causes the original command to be expanded into a series of similar command instances.

Implementer's note: detection of PDU overflow must occur at a point where there is still room in the PDU for the error descriptor.

Package: - 
Reference: No 

> From: Christian Groves [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > From: Christer Holmberg [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > [ mailto:[email-masked] <mailto:[email-masked]> ] 
> > > > > [ mailto:[email-masked] <mailto:[email-masked]> ]

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Wed, 28 Mar 2001 10:26:09 +0200

Hello 
I think the sentence Christian proposed how additional transactions shall be terated shall not be in the definition of the error code. It should be in the text in section 8 in H.248. Therefore I also propose to make a reference to section 8 where the future treatment of the commmands and thr transaction are (will ) be described

Definition: The MG or MGC is unable to assemble a complete transaction
response because the number of bytes for the message would exceed the
maximum protocol data unit size if the underlying transport. The command
instance in the response to that would have cause the overflow is
treated as if it were in error, and the reminder of the transaction is
not executed. 
Note:This situation will typically arise in conjunction with the use of
wildcarding, which causes the original command to be expanded into a
series of similar command instances.
If the request contained wildcarded a termination ID the MGC or MG
should send later requests with a smaller subset of termination Ids.
Package: -
Reference: Section 8
Error Text in the error Descriptor: NA
Comment: Implementors' note: the detection of PDU overflow must occur at
a point where there is still room in the PDU for the error descriptor.
-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: den 28 mars 2001 05:24
To: Tom-PT Taylor
Cc: Christer Holmberg; 'Dave Sclarsky'; [email-masked];
[email-masked]; Alf Heidermark
Subject: Re: How does the MGC rebuild a long transaction in ALF/UDP

G'Day Tom, all,

I do think this is important but I think it at the moment can be handled
by the addition of an error code. It gives an means of indicatin a
problem. How the MG determines the message length is an implementation
issue. 

I don't believe a "megaco extension" is the way to go as there is no
such thing and I would not be supportive to adding it. You also have the
choice not to use ALF/UDP and use something more reliable.

So I think H.248v2 is the correct place to do a robust solution.

Taking in the comments on the error code how about?

2.58 Error Code # : 534 Name: Response exceeds maximum transport PDU
size
Definition: The MG or MGC is unable to assemble a complete transaction
response because the number of bytes for the message would exceed the
maximum protocol data unit size if the underlying transport. The command
instance in the response to that would have cause the overflow is
treated as if it were in error, and the reminder of the transaction is
not executed. If the message reply was to contain several transactions
these subsequent transactions should be placed in separate messages.
This situation will typically arise in conjunction with the use of
wildcarding, which causes the original command to be expanded into a
series of similar command instances.
If the request contained wildcarded a termination ID the MGC or MG
should send later requests with a smaller subset of termination Ids.
Package: -
Reference: No
Error Text in the error Descriptor: NA
Comment: Implementors' note: the detection of PDU overflow must occur at
a point where there is still room in the PDU for the error descriptor.

Cheers, 
Christian

Christer Holmberg wrote:
> 
> Hi,
> 
> >This is a real issue.  Presumably, if Megaco provided for message segmentation, your encoding layer would be >the place where it was implemented.  Right now your only choices are to avoid UDP or change the API radically >to let you push down the results of each command separately and get feedback on the results.
> >
> >So how much priority should we give this?  Should we try to get it onto our Megaco charter so we can deal with >it through the RFC process as a Megaco extension (leaving SG 16 to catch up), or should we leave it for >H.248v2?
> 
> I think we should give this some priority. It's not a big issue, but I
> think it will be very useful. And, by doing it I am pretty sure we will
> avoid some strange things happening when we do wildcarded Audits (or
> other commands) on UDP...
> 
> I do agree with Dave's arguments, but this is the easiest (probably even
> the only possible) way to solve this issue for v1.
> 
> >Should 50 command replies be returned and for the 51st command an error returned
> Like Tom said, that would be normal behaviour. I think, however, that
> the MG should also be able to send the error already for the first
> command, if it knows that the reply message will be too big.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland

---

From: "Marcello Pantaleo (EED)" <[email-masked]>
Date: Wed, 28 Mar 2001 11:16:40 +0200

Hi Christian,

what does it happen if the command originating overflow
in the response was marked as "Optional" and the succeeding one 
(suppose the last one in the transaction)if executed doesn't cause overflow?
I guess it would be better to say:
"
Definition: The MG or MGC is unable to assemble a complete transaction
response because the number of bytes for the message would exceed the
maximum protocol data unit size if the underlying transport. The command
instance in the response to that would have cause the overflow is
treated as if it were in error, and the reminder of the transaction is
not executed, even if the command instance was marked as "Optional".....
"

Cheers,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 5:24 AM
To: Tom-PT Taylor
Cc: Christer Holmberg; 'Dave Sclarsky'; [email-masked];

G'Day Tom, all,

Cheers, 
Christian

---

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Wed, 28 Mar 2001 12:36:29 +0200

Marcello
But since tha action is the same independent on whether optional is used or not, is there any reason to add these words.

-----Original Message-----
From: Marcello Pantaleo (EED) [mailto:[email-masked]]
Sent: den 28 mars 2001 11:17
To: 'Christian Groves'
Cc: [email-masked]'
Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

Hi Christian,

Cheers,
Marcello

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 5:24 AM
To: Tom-PT Taylor
Cc: Christer Holmberg; 'Dave Sclarsky'; [email-masked];

G'Day Tom, all,

Cheers, 
Christian

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 28 Mar 2001 09:59:13 -0500

I'd leave this one up to implementors.  A really painstaking implementation
would look ahead to see if the next response would fit, but it's not going
to affect interoperability one way or the other.  The one warning here is
that if an "O-" command is skipped under these circumstances, an error
descriptor has to be provided so the requestor knows what has happened.

> From: Marcello Pantaleo (EED) 
> [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2001 4:17 AM
> To: 'Christian Groves'
> Cc: [email-masked]'
> > >This is a real issue.  Presumably, if Megaco provided for 
> message segmentation, your encoding layer would be >the place 
> where it was implemented.  Right now your only choices are to 
> avoid UDP or change the API radically >to let you push down 
> the results of each command separately and get feedback on 
> the results.
> > >
> > >So how much priority should we give this?  Should we try 
> to get it onto our Megaco charter so we can deal with >it 
> through the RFC process as a Megaco extension (leaving SG 16 
> to catch up), or should we leave it for >H.248v2?
> >

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 28 Mar 2001 08:26:48 -0500

The text looks OK.  Whether we do a Megaco extension which gets taken up
into H.248v2 is up to the list.

> Sent: Tuesday, March 27, 2001 10:24 PM