Subject: RE: ASN or ABNF

From: "Goel, Mukesh" <[email-masked]>
Date: Mon, 23 Apr 2001 10:42:19 -0700

Hi Brian, others,

Isn't the encoding scheme decision based on the
port number that MGC receives ServiceChnage on.

2944 for ABNF and
2945 for ASN.
Reference "Section 9. Transport" of RFC 3015

Mukesh

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Monday, April 23, 2001 10:08 AM
To: 'Sivakoti, Suresh'; [email-masked]'
Subject: RE: ASN or ABNF

This question belongs on the main megaco mail list

The answer is that you figure it out from the first message (ServiceChange).
You can figure it out from the first byte of the first message.
Nearly all implementations use text.  A small number of implementations
use text and binary.  I saw one implementation of an MG that was binary
only,
but I suspect they have added text since then.

Brian

> -----Original Message-----
> From: Sivakoti, Suresh [mailto:[email-masked]]
> Sent: Monday, April 23, 2001 12:16 PM
> To: [email-masked]
> Subject: ASN or ABNF
> 
> 
> RFC-3015  section 7.2.1o specifies that MGC should support 
> both ASN and
> ABNF, where as MGs may support both. I intrepret this 
> statement as MGs does
> not need to support both formats, If they support either format.
> 
> In this case, how does MG lets MGC about the protocol 
> encoding/decoding it
> is currently using in the serviceChange Request ?.
> Is there a rule that says support for ABNF is mandatory for 
> MGs and ASN is
> optional or vice-versa. If there is no such restrction, then 
> what is the
> popular choice of  protocol encoding for MGs ?.
> Is there a possibilty that MG changes protocol encoding from 
> ASN<--->ABNF
> durinng active session ( without serviceChange request).
> 
> What are the current practices of implementing parser for 
> Megaco, is it one
> for text and one for ASN ?.
> 
> Is there any sample data available to evaluate parsers 
> implementation ?.
> 
> the above questions might have obvious answers but not for 
> me, as I just
> started to working on implementing a MGC.
> 
> Thanks for your support.
> 
> Suresh Sivakoti
>  
>

---

From: "Paul Long" <[email-masked]>
Date: Mon, 23 Apr 2001 15:49:50 -0500

Regarding the following, how does one "negotiate the profile?" Let's say
that the MG's ServiceChange request indicates the "IPPhone" profile and the
MGC's response indicates the "NotTheIPPhone" profile. How does the MG
indicate that it supports and accepts this profile, and, conversely, that it
rejects this profile?

7.2.8/H.248: "The return from ServiceChange is empty except when the Root
terminationID is used.  In that case it includes the following parameters as
required: [...] · ServiceChangeProfile, if the responder wishes to negotiate
the profile to be used for the association;"

Paul Long
ipDialog, Inc.

---

From: "Sarju Garg" <[email-masked]>
Date: Tue, 24 Apr 2001 17:08:03 +0530

Hi Lists,

I have a query related to the call flow (Appendix A section A.1.2 step 12)
shown in the H.248 document. Why is the mode of the termination A4444 not
set to sendonly? Since the default state is inactive, then how will the
caller hear the RBT applied by the terminating exchange (if mode!=sendonly)?
Also mode in step 3 is set to send/recv. Why is that so? We do not need to
set mode now. Let it be inactive and change mode only in step 12 to sendonly
TIA
Sarju