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

From: "Michael Brown" <[email-masked]>
Date: Wed, 28 Mar 2001 11:23:31 -0500

I think it is an important distinction because it is an exception to the
intent of marking a command as optional. An optional command that fails
should USUALLY be ignored and processing subsequent commands be allowed to
proceed. Because of that, I would say we should explicitly identify that
exception.

Michael

-----Original Message-----
From: Alf Heidermark (UAB) [mailto:[email-masked]]
Sent: Wednesday, March 28, 2001 5:36 AM
To: Marcello Pantaleo (EED); 'Christian Groves'
Cc: [email-masked]'
Subject: RE: How does the MGC rebuild a long transaction in ALF/UDP

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,

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];
[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.
> 
> >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?
> 
> 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: Christian Groves <[email-masked]>
Date: Thu, 29 Mar 2001 13:12:32 +1000

I think that Alf has a point here. Optional is purely on commands. The
actual error code says that the "the reminder of the transaction is not
executed". Optional doesn't come into play here.

Alf: i'll remove the sentence you proposed.

Regards, Christian

Michael Brown wrote:
> 
> I think it is an important distinction because it is an exception to
> the intent of marking a command as optional. An optional command that
> fails should USUALLY be ignored and processing subsequent commands be
> allowed to proceed. Because of that, I would say we should explicitly
> identify that exception.
> 
> Michael
> 
> But since tha action is the same independent on whether optional is
> used or not, is there any reason to add these words.
> 
> From: Marcello Pantaleo (EED)
> [mailto:[email-masked]]
> 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?
> 
> >
> > >For the wildcarded command case, said if the wildcarded command
> expands into
> > >Should 50 command replies be returned and for the 51st command an
> error returned