Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

From: "Raphael Tryster" <[email-masked]>
Date: Wed, 15 Nov 2006 10:04:55 +0200

Hello Kevin,

What is the status of this part of the standard?  I seem to remember
something was published, but I can't find it now, and fax seems to have
taken the name Annex F.

There was also a document called
draft-hss-megaco-control-association-state-machine-00.txt, expired
2/2002.  Did it become standard?  I noticed it says, among other things,
that the Disconnected method is only allowed from MG to MGC.  However, I
have seen it used in the other direction for heartbeat.  Is this
standard or proprietary?

Raphael Tryster

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 10:00 PM
To: Aleksandr Ryabin; Chuong N. Nguyen; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

My apologies on the typo.

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:39 PM
To: Chuong N. Nguyen; [email-masked]
Subject: Re: [Megaco] ServiceChange procedures -- future Annex F

Try (note "_" in dir name)
ftp://standards.pictel.com/avc-site/0206_Bru/TD-41a.zip

At 03:30 PM 7/23/2002, Chuong N. Nguyen wrote:

Hi Kevin 

I have trouble getting this doc. 

Can you verify? 

Thanks 
Chuong 

Kevin Boyle wrote: 

All, 

At the June Rapporteur's meeting, baseline text was accepted for what
will
eventually become Annex F.  This Annex covers ServiceChange procedures,
putting definitions on common terms (like registration and control
association) and delving into behavior of ServiceChange on Root.  Work
on
this is expected to complete mid to late 2003. 

I encourage you all to read the document, as work will progress on it at
future ITU meetings.  Any comments, issues, questions, etc., should be
posted here.  There is a lot of work left to do, such as defining
non-root
behavior and clarifying a number of questions that the document poses. 

Until such time as the document can be posted to the Megaco web site,
you
can retrieve it from: 

ftp://standards.pictel.com/avc-site/0206Bru/TD-41a.zip 

Kevin

-- 
  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]
https://www1.ietf.org/mailman/listinfo/megaco
**********************************************************************************************
This e-mail contains confidential, privileged or proprietary information to VocalTec Communications.
If you received this messege by mistake, please inform us and then delete the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious content. ***
**********************************************************************************************

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

---

From: [email-masked]
Date: Wed, 15 Nov 2006 18:42:30 +0100

Try to answer the questions:
1) Annex F
      In the meanwhile published with H.248.1 Version 3.

http://www.itu.int/rec/T-REC-H.248.1/recommendation.asp?lang=en&parent=T-REC-H.248.1-200509-I

2) draft-hss-megaco-control-association-state-machine-00.txt
      This was an attempt in mapping ServiceChange procedures on a specific
      state machine, with a set of states which were not yet defined in
      H.248.1. [Such an attempt would be always welcome in my opinion, in
      particular when using a formal specification method (like UML, SDL,
      etc), and could be e.g. done in the scope of H.248.1 Version 4.]

      The draft itself is dead, but in H.248.1 Version 3 was the concept of
      the "control association" defined, and a "simple ServiceChange state
      model" described in F.1. This is a solution sth in between H.248.1 V1
      text and the scope of this draft.
      E.g., the Control Association itself has not yet any explicit state
      description, it could be modelled by a 2-state machine {"successfully
      establised", "not existing"}, or in case of a time-dependent
      consideration could be a third state "in establishment" considered,
      too. Or "ServiceChange" states are not yet related to OAM state
      models (like operational states).
      Guess such a wide scope was aimed by that draft.

3) ServiceChangeMethod "Disconnect"
      Yes, only from MG-to-MGC, and only together with Reason codepoints
908, 909, 916 or 917.
      See e.g. Table F.1/H.248.1 Version 3.

- Albrecht

                      "Raphael Tryster"                                                                                                    
                      <raphael.tryster@vo         To:      "Kevin Boyle" <[email-masked]>, <[email-masked]>                    
                      caltec.com>                 cc:                                                                                      
                                                  Subject: RE: [Megaco] ServiceChange procedures -- future Annex F                         
                      15.11.2006 09:04                                                                                                     

Hello Kevin,

Raphael Tryster

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 10:00 PM
To: Aleksandr Ryabin; Chuong N. Nguyen; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:39 PM
To: Chuong N. Nguyen; [email-masked]
Subject: Re: [Megaco] ServiceChange procedures -- future Annex F

Hi Kevin

Can you verify?

Thanks
Chuong

Kevin Boyle wrote:

All,

Kevin

This e-mail contains confidential, privileged or proprietary information to
VocalTec Communications.
If you received this messege by mistake, please inform us and then delete
the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious content.
***
**********************************************************************************************

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 15 Nov 2006 10:23:03 -0500

Annex F was ratified as part of H.248.1 Version 3 in September 2005.

The fax packages are in H.248.2.  This was (some years ago) known as
Annex F, but was renumbered to be H.248.2 in 2002.

The IETF document you mention was never ratified, as it was seen to be
overly complex and onerous.  Annex F defines which ServiceChangeMethods
may be used with particular termination types (Root, physical and
ephemeral) and in which direction.  Per Clauses F.4.1.1, F.4.1.2 and
F.4.1.3, Disconnected may only be used with Root and in the MG->MGC
direction.

Kevin

-----Original Message-----
From: Raphael Tryster [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 3:05 AM
To: Kevin Boyle; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

Hello Kevin,

Raphael Tryster

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 10:00 PM
To: Aleksandr Ryabin; Chuong N. Nguyen; [email-masked]
Subject: RE: [Megaco] ServiceChange procedures -- future Annex F

Kevin

-----Original Message-----
From: Aleksandr Ryabin [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:39 PM
To: Chuong N. Nguyen; [email-masked]
Subject: Re: [Megaco] ServiceChange procedures -- future Annex F

Hi Kevin 

Can you verify? 

Thanks
Chuong 

Kevin Boyle wrote: 

All, 

Kevin

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco
************************************************************************
**********************
This e-mail contains confidential, privileged or proprietary information
to VocalTec Communications.
If you received this messege by mistake, please inform us and then
delete the original and all copies.
*** eSafe scanned this email for viruses, vandals, and malicious
content. ***
************************************************************************
**********************