Subject: [Megaco] Whats the best tutorial to start megaco

From: "Bukka, Veerasham" <[email-masked]>
Date: Fri, 3 Aug 2001 17:14:31 -0400

Hi All,
 
Can you tell me what is the best Megaco tutrial on the web, which will
give an immediate understanding to the reader and assumes some basic MG
concept from the reader?
What is the best tutorial to understand megaco for a person, who already
know MGCP and want to change to Megaco?
 
Thanks,
/
Veeresh

-----Original Message-----
From: Chuong N. Nguyen [mailto:[email-masked]]
Sent: Friday, August 03, 2001 4:06 PM
To: [email-masked]
Subject: Re: [Megaco] ServiceChangeReason parameter

Kevin 

If you look at Annex L. 

Reason # : 901 Name: Cold Boot 
Definition: This indicates that the entity indicated with the
TerminationID is in serviceState "In-Service", and that it has gone
through a start or recovery action and all associated contexts except
the null context have been cleared. 
Reference: - 
Text in the Service Change extension: - 
Comment: This reason code only applies for TerminationID root and ALL. 

901 implies MGC does not have to sent Subtract to MG. 

Reason # : 902 Name: Warm Boot 
Definition: This indicates that the entity indicated with the
TerminationID  is in ServiceState "in-Service", and that it has gone
through a start or recovery action. All transactions in process may be
lost, but otherwise all state is preserved on the termination. 

902 implies that there are terminations in contexts which might or might
require MGC 
to Subtract thems. 

It really depends on MG implementation. 
If MG has a processor that strictly handles Megaco signaling and it is
just this processor 
that gets rebooted, there is no reason for established calls to be
teared down. 
So MG can re-establish w/Warm boot. 

I know of one MG vendor that does actually send Restart w/Warm boot and 
the terminations are intact in the contexts. 

Yes, there are cases whether Method and Reason are redundant and
confusing. 

Chuong 

Kevin Boyle wrote: 

I haven't seen any cases where Reason should be required.  I agree
Method is absolutely required, as it defines the behavior taken by the
receiving party. In what scenario does Reason alter the behavior that
would occur for a given Method?  Unless there are some concrete cases
where the behavior is completely different, I would think that Reason
should be optional. 

Kevin 

 -----Original Message----- 
From:   Terry L Anderson [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent:   Friday, August 03, 2001 12:30 PM 
To:     Christian Groves 
Cc:     [email-masked]; [email-masked] 
Subject:        Re: [Megaco] ServiceChangeReason parameter 

 << File: Card for Terry L Anderson >> By "too subtle" I only meant a
parameter being mandatory being stated only in the body of 

H.248 and not in the syntax spec (when other similar
restrictions/requirements ARE stated 
in the syntax spec).  You seem to agree that adding a comment in the
ABNF is good. 

The IG has already added two comments before serviceChangeParm 
(6.5) ; each parameter at-most-once 
(6.72) ;at most one of either serviceChangeAddress or serviceChangeMgcId
but not both 

I propose we add one additional comment 

; serviceChangeMethod and serviceChangeReason are REQUIRED 

Christian Groves wrote: 

> No I don't believe its too subtle. The binary has Service Change
Reason 
> and Method as mandatory as per the text. The ABNF because of its 
> specification can't enforce this, so yes a comment is needed. If the 
> reason is neglected what does the MGC do? The reasons were given to
add 
> some meaning to the Methods. 
> 
> Christian 
> 
> Terry L Anderson wrote: 
> > 
> > Christian Groves wrote: 
> > 
> > > Hello Terry, 
> > > 
> > > I believe the ASN.1 is correct if you read the procedural text in 
> > > ch7.2.8 every element says "The optional", ServiceChangeMethod and

> > > ServiceChangeReason does not have this qualification. 
> > 
> > Isn't that a bit too subtle and shouldn't this be in the ABNF
comments. 
> > 
> > > 
> > > 
> > > Christian 
> > > 
> > > Terry L Anderson wrote: 
> > > > 
> > > > This is another difference between the text and binary versions.
The ASN.1 
> > > > clearly requires serviceChangeMethod and serviceChangeReason in
each 
> > > > ServiceChange command with all other parameters optional, but
the ABNF simply 
> > > > states (in comments added in IG 6.5 and 6.72) that each item can
appear at most 
> > > > once and only one of ServiceChangeAddress and ServiceChangeMgcId
- no element 
> > > > is required. 
> > > > 
> > > > I am not sure that this difference was intentional but that is
the current 
> > > > state of the spec.  Do we want the ABNF to also require
ServiceChangeMethod and 
> > > > ServiceChangeReason?  The registration in the text-based example
in A.1.1 
> > > > contains a Method but not a Reason. 
> > > > 
> > > > IPEK SARAC wrote: 
> > > > 
> > > > > Hello, 
> > > > > 
> > > > > RFC3015 doesn't mention if ServiceChangeReason for
ServiceChange command is 
> > > > > mandatory or optional (it doesn't say optional so i take it as
required). 
> > > > > Megaco Call Flow Examples draft doesn't include a
ServiceChangeReason in 
> > > > > cold start scenario. Which one is true? 
> > > > > 
> > > > > Thanks in advance. 
> > > > > 
> > > > > Ipek Sarac 
> > > > > 
> > > > > _______________________________________________ 
> > > > > Megaco mailing list 
> > > > > [email-masked] 
> > > > > http://www.ietf.org/mailman/listinfo/megaco
<http://www.ietf.org/mailman/listinfo/megaco>  
> > > > 
> > > > -- 
> > > > Waiting for the other shoe to drop but hoping its a one legged
man. 
> > > > ------------------------------------------------------------ 
> > > > Terry L Anderson             mailto:[email-masked]
<mailto:[email-masked]>  
> > > > Tel:908.582.7013   Fax:908.582.6729 
> > > > Lucent Technologies/INS/Voice Over IP Access Networks 
> > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
> > > > http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla>  
> > 
> > -- 
> > Waiting for the other shoe to drop but hoping its a one legged man. 
> > ------------------------------------------------------------ 
> > Terry L Anderson             mailto:[email-masked]
<mailto:[email-masked]>  
> > Tel:908.582.7013   Fax:908.582.6729 
> > Lucent Technologies/INS/Voice Over IP Access Networks 
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
> > http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla>  

-- 
Waiting for the other shoe to drop but hoping its a one legged man. 
------------------------------------------------------------ 
Terry L Anderson             mailto:[email-masked]
<mailto:[email-masked]>  
Tel:908.582.7013   Fax:908.582.6729 
Lucent Technologies/INS/Voice Over IP Access Networks 
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 
http://its.lucent.com/~tla <http://its.lucent.com/~tla>  (Lucent
internal) http://www.gti.net/tla <http://www.gti.net/tla> 

-- 

  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 ****

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