Subject: [Megaco] Help

From: "sunil vatnal" <[email-masked]>
Date: Wed, 18 Jun 2003 18:54:13 +0530

Hi,

1. When vendors claim ALF support for MEGACO, do they consider 1 MEGACO
transaction as 1 ADU ?
2. Do these vendor send multiple transactions in one MEGACO Message ?

Atul
Mahindra British Telecom Ltd
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 18, 2003 12:27 AM
Subject: Megaco digest, Vol 1 #917 - 3 msgs

> Send Megaco mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www1.ietf.org/mailman/listinfo/megaco
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Megaco digest..."
>
>
> Today's Topics:
>
>    1. Re: v2 mismatch ABNF & ASN.1 IndAudmediaParm? (Christian Groves)
>    2. what is ALF ( Application Level Framing ) (sunil vatnal)
>    3. Query regarding ALF in MEGACO (Shailendra)
>
> --__--__--
>
> Message: 1
> Date: Tue, 17 Jun 2003 10:58:51 +1000
> From: Christian Groves <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [Megaco] v2 mismatch ABNF & ASN.1 IndAudmediaParm?
>
> Hello Micael,
>
> I don't understand what the problem is nor the comments in the ASN.1 you
are
> referring to? If you are referring to the ::= SEQUENCE this is actually an
ASN.1
> construct that says that a sequence of information elements may be
encoded, in
> this case "termStateDescr" & a choice of streams. This same information is
> represented by the ABNF.
>
> Regards, Christian
>
> Micael Karlberg wrote:
> >
> > Hi,
> >
> > In draft-ietf-megaco-h248v2-04.txt there appear to be a mismatch
> > between the ABNF and the ASN.1 regarding indAudmediaDescriptor.
> > My question is: Should the definition of ABNF indAudmediaDescriptor
> > really be:
> >
> >       indAudmediaDescriptor   = MediaToken LBRKT indAudmediaParm
> >                                 *(COMMA indAudmediaParm) RBRKT
> >
> > The comment for indAudmediaParm and the ASN.1 IndAudMediaDescriptor
> > indicates that it should be a list. Or am I missing something?
> >
> > Also, see definition of mediaDescriptor!
> >
> > ABNF:
> > ----
> >       indAudmediaDescriptor   = MediaToken LBRKT indAudmediaParm RBRKT
> >
> >       ; at-most-once per item
> >       ; and either streamParm or streamDescriptor but not both
> >       indAudmediaParm = (indAudstreamParm / indAudstreamDescriptor /
> >                          indAudterminationStateDescriptor)
> >
> > ASN.1:
> > -----
> >       IndAudMediaDescriptor ::= SEQUENCE
> >       {
> >
> >          termStateDescr    IndAudTerminationStateDescriptor OPTIONAL,
> >          streams  CHOICE
> >                {
> >                   oneStream      IndAudStreamParms,
> >                   multiStream    SEQUENCE OF IndAudStreamDescriptor
> >                } OPTIONAL,
> >          ...
> >       }
> >
> > Regards,
> >         /BMK
> >
> > _______________________________________________
> > Megaco mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/megaco
>
> --__--__--
>
> Message: 2
> Date: Tue, 17 Jun 2003 13:06:40 +0530
> From: "sunil vatnal" <[email-masked]>
> To: <[email-masked]>
> Cc: "krishnappa" <[email-masked]>
> Date: Tue, 17 Jun 2003 13:02:17 +0530
> Organization: mbt
> Subject: [Megaco] what is ALF ( Application Level Framing )
>
> This is a multi-part message in MIME format.
>
> ------=_NextPart_000_004D_01C334D0.AE512020
> Content-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> Hi,
>
> The megaco RFC 3015 suggests to implement ALF ( Application Level =
> Framing ) for the UDP transport. The meaning of the ALF is like this in =
> the RFC.
>
> " ALF is a set of techniques that allows an application, as opposed to a =
> stack, to affect how messages are sent to the other side. A typical ALF =
> technique is to allow an application to change the order of messages =
> sent when there is a queue after it has queued them.  There is no formal =
> specification for ALF.=20
>    Implementors using IP/UDP with ALF SHOULD be aware of the =
> restrictions of the MTU on the maximum message size. "
>
> Most of the Megaco Protocol Stack developers say that they have achieved =
> the ALF by implementing reliable transactions by having retransmissions, =
> provisional transmissions, rejection of duplicate transactions...etc.
>
> My Question is .... =3D=3D=3D> Can we achieve ALF by ..=20
>
>    1) implementing reliable transactions with retransmission techniques =
> with long timer
>        mechanism ( This is already implemented )
>
>                                             -- OR --=20
>
>    2) Fragment and reassemble the message or the media data depending =
> upon the MTU size.
>   =20
>                                             -- OR --
>    3) Divide the message or the media data into ADUs ( Application Data =
> Units ) and keep track=20
>        of the order of these.
>
>    Please clarify..
>
>   Thanks and Regards,
>   Sunil M Vatnal
>   Mahindra British Telecom.
>
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains=20
> confidential information intended for a specific=20
> individual and purpose, and is protected by law.=20
> If you are not the intended recipient, you should=20
> delete this message and are hereby notified that=20
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,=20
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
>
> ------=_NextPart_000_004D_01C334D0.AE512020
> Content-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Diso-8859-1">
> <META content=3D"MSHTML 5.50.4522.1800" name=3DGENERATOR>
> <STYLE></STYLE>
> </HEAD>
> <BODY bgColor=3D#e6e6e6>
> <DIV><FONT face=3DArial size=3D2>
> <DIV><FONT face=3DArial size=3D2>Hi,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>The megaco RFC 3015 suggests to =
> implement ALF (=20
> Application Level Framing ) for the UDP transport. The meaning of the =
> ALF is=20
> like this in the RFC.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2>" ALF is a set of =
> techniques that=20
> allows an application, as opposed to a stack, to affect how messages are =
> sent to=20
> the other side. A typical ALF technique is to allow an application to =
> change the=20
> order of messages sent when there is a queue after it has queued =
> them.&nbsp;=20
> There is no formal specification for ALF. <BR>&nbsp;&nbsp; Implementors =
> using=20
> IP/UDP with ALF SHOULD be aware of the restrictions of the MTU on the =
> maximum=20
> message size. "</FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>Most of the Megaco Protocol Stack =
> developers say=20
> that they have&nbsp;achieved the ALF by implementing reliable =
> transactions by=20
> having retransmissions, provisional transmissions, rejection of =
> duplicate=20
> transactions...etc.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>My Question is .... =3D=3D=3D&gt; Can =
> we achieve ALF by=20
> .. </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 1) implementing reliable =
> transactions=20
> with&nbsp;retransmission techniques with long timer</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> mechanism ( This is=20
> already implemented )</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial=20
> size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
> ;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;--=20
> OR -- </FONT></DIV>
> <DIV>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 2) Fragment and reassemble =
> the message=20
> or the media data depending upon the MTU size.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
> &nbsp;&nbsp;&nbsp;=20
> &nbsp;&nbsp;&nbsp; -- OR --</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; 3)&nbsp;Divide the message =
> or the=20
> media data into ADUs ( Application Data Units ) and keep track =
> </FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of =
> the order=20
> of these.</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp; Please =
> clarify..</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp; Thanks and Regards,</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp; Sunil M Vatnal</FONT></DIV>
> <DIV><FONT face=3DArial size=3D2>&nbsp; Mahindra British=20
> Telecom.</FONT></DIV></FONT></DIV></BODY></HTML>
>
> <html>
> <br>
> *********************************************************<br>
> Disclaimer<br>
> <br>
> This message (including any attachments) contains <br>
> confidential information intended for a specific <br>
> individual and purpose, and is protected by law. <br>
> If you are not the intended recipient, you should <br>
> delete this message and are hereby notified that <br>
> any disclosure, copying, or distribution of this<br>
> message, or the taking of any action based on it, <br>
> is strictly prohibited.<br>
> <br>
> *********************************************************<br>
> Visit us at http://www.mahindrabt.com<br>
> <br>
> </html>
>
> ------=_NextPart_000_004D_01C334D0.AE512020--
>
>
>
> --__--__--
>
> Message: 3
> Date: Tue, 17 Jun 2003 17:27:25 +0530
> Reply-To: "Shailendra" <[email-masked]>
> From: "Shailendra" <[email-masked]>
> To: <[email-masked]>
> Date: Tue, 17 Jun 2003 17:26:08 +0530
> Organization: Mahibdra - British Telecom
> Subject: [Megaco] Query regarding ALF in MEGACO
>
> Hi,
>
> The megaco RFC 3015 suggests to implement ALF ( Application Level
Framing )
> for the UDP transport. The meaning of the ALF is like this in the RFC.
>
> " ALF is a set of techniques that allows an application, as opposed to a
> stack, to affect how messages are sent to the other side. A typical ALF
> technique is to allow an application to change the order of messages sent
> when there is a queue after it has queued them. There is no formal
> specification for ALF.
>    Implementors using IP/UDP with ALF SHOULD be aware of the restrictions
of
> the MTU on the maximum message size. "
>
> Most of the Megaco Protocol Stack developers say that they have achieved
the
> ALF by implementing reliable transactions by having retransmissions,
> provisional transmissions, rejection of duplicate transactions...etc.
>
> My Questions is .... Can we achieve ALF by ..
>
>    1) implementing reliable transactions with retransmission techniques
with
> long timer
>        mechanism ( This is already implemented )
>
>                                             -- OR --
>
>    2) Fragment and reassemble the message or the media data depending upon
> the MTU size.
>
>                                             -- OR --
>    3) Divide the message or the media data into ADUs ( Application Data
> Units ) and keep track
>        of the order of these.
>
>    Please clarify..
>
>   Thanks and Regards,
> Shailendra
>
> *********************************************************
> Disclaimer
>
> This message (including any attachments) contains
> confidential information intended for a specific
> individual and purpose, and is protected by law.
> If you are not the intended recipient, you should
> delete this message and are hereby notified that
> any disclosure, copying, or distribution of this
> message, or the taking of any action based on it,
> is strictly prohibited.
>
> *********************************************************
> Visit us at http://www.mahindrabt.com
>
>
>
>
>
> --__--__--
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco
>
>
> End of Megaco Digest
>

*********************************************************
Disclaimer

This message (including any attachments) contains 
confidential information intended for a specific 
individual and purpose, and is protected by law. 
If you are not the intended recipient, you should 
delete this message and are hereby notified that 
any disclosure, copying, or distribution of this
message, or the taking of any action based on it, 
is strictly prohibited.

*********************************************************
Visit us at http://www.mahindrabt.com

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: "sunil vatnal" <[email-masked]>
Date: Wed, 18 Jun 2003 18:54:13 +0530

Hi,

Atul
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 18, 2003 12:27 AM
Subject: Megaco digest, Vol 1 #917 - 3 msgs

are
ASN.1
encoded, in
Framing )
of
the
with