Subject: Re: [Megaco] VDY:>> MGC Failure

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 12:30:54 -0400

Gunter Weiss wrote:

>Hello all,
>
>although I had a look to this discussion right now still one or two question remain
>unclear to me:
>
>first of all:
>- assuming the MG tried to contact a secondary MGC with retries, but the secondary
>  MGC does not answer- the MG has to contact the primary MGC (failed one) again.
>  But how shall this one be contacted according H248 v1??
>  In H248v2 it is stated :
> "When contacting its previously controlling MGC the MG sends the
>   ServiceChange message with "Disconnected" method!"
>  This is clear to me and logically!
> This assumes that the MGC knows the MG as a registered one!
>  Unfortunatly this is not explicitly mentioned in H248v1!
>
not in the original text of v1 but it was added through the Implementors 
Guide and DOES appear in the H.248.1 (the latest text for v1).

>  Its also not logically that the MG send SVCH (restart or failover) to the failed MGC,
>  because it does not know what happend to that MGC.
>
The failed MGC may have recovered or the failure may have been a 
temporary failure in the network, etc. So after trying the provisioned 
alternates, it will retry the original MGC, continuing the cycle until 
some MGC accepts it. MG does not need to know what happened to the MGC, 
it just wants to find one that accepts it.

>second point - but related:
>  assuming the MGC would answer on the SVCH (disconnected) with a negative
>  reply (504 - unautherized ...) - because it lost the registered state of the MG.
>  What should be the reaction of the MG?
>  SVCH (restart) to get registered again  - but what reasoncode ??
>
I believe it should send restart. I am not sure there is a perfect 
reason but perhaps 900 Service Restored

>
>-- ,
>Gunter
>
>Kevin Boyle wrote:
>
>  
>
>>Disconnect is only used if the MG goes back to the MGC it was communicating
>>with when problems started.  If it goes to any other MGC, it must use
>>Handoff or Failover as appropriate.  Either way, it is up to the MGC how to
>>handle the MG when these scenarios occur.
>>
>>Further comments inline [KJBII].
>>
>>Kevin
>>
>>-----Original Message-----
>>From: Kaul, Bharat [mailto:[email-masked]]
>>Sent: Wednesday, February 20, 2002 5:53 PM
>>To: Boyle, Kevin [NCRTP:3Z30:EXCH]; Kaul, Bharat; 'P.S.K. Chakravarthi';
>>vidya g
>>Cc: [email-masked]
>>Subject: RE: [Megaco] VDY:>> MGC Failure
>>
>>Ummm..there seems to be an implication that from practical point of the view
>>all three cases should be equivalent (to handoff) with new MGC relying on
>>audit to discover MG states. I would agree with you ideally but I forsee
>>some issues as listed below.
>>
>>For example 1 (and example 3), it would seem that if we want MG to maintain
>>contexts, the MG should send a ServiceChange with "disconnect method" to the
>>new MGC. There are two cases:
>>
>>* MGC knows about MG
>>
>>  This case is simpler. MGC audits and moves forward.
>>
>>[KJBII] How would the MG know that the MGC "knows about" it?  It doesn't,
>>and therefore can make no assumptions as to how to behave.  The MGC will
>>take any actions it deems appropriate.
>>
>>* MGC does not know about MG
>>
>>  Since "disconnect" is not the way to register with the MGC, MGC will have
>>to send an error response. Does this error response imply MG has to cleanup
>>? I guess not.
>>
>>[KJBII] Unless the MG is communicating back with the "failed" MGC, then
>>Disconnected should not be used.  If there is a control change to a new MGC,
>>then Handoff or Failover must be used.  Again I ask: How does the MG know
>>that the MGC doesn't "know about" it?  The MG does not have this knowledge,
>>and therefore cannot assume that the MGC is not capable of continuing the
>>contexts that are in existence.  It must wait for the MGC to clean it up, if
>>necessary.
>>
>>If it doesn't have any more MGC's provisioned what does MG do ?
>>
>>[KJBII] It waits a random amount of time, and attempts to contact the MGCs
>>that are provisioned in its list.  This is described in the spec.
>>
>>If it has more MGC's provisioned, it can end up in example 3, where MG will
>>keep going to different MGC's. Because of transaction time out related
>>issues (e.g. what if secondary MGC doesn't respond), what choice does MG
>>have ?
>>
>>[KJBII] Once the MG has exhausted its list, it waits a random amount of
>>time, and then starts again through its list.  Once the MG finally makes
>>contact with an MGC, the MGC can take whatever action it deems appropriate.
>>Until that time, the MG can make no assumptions as to whether the MGC it
>>will eventually be controlled by is capable of continuing the existing
>>contexts or not.
>>
>>- Bharat
>>
>>-----Original Message-----
>>From: Kevin Boyle [mailto:[email-masked]]
>>Sent: Wednesday, February 20, 2002 2:23 PM
>>To: Kaul, Bharat; 'P.S.K. Chakravarthi'; vidya g
>>Cc: [email-masked]
>>Subject: RE: [Megaco] VDY:>> MGC Failure
>>
>>Wait a minute... You have indicated that a MG may clean up contexts on its
>>own.  This is certainly not described in the spec, and I strongly advise
>>against it.  For the first case, it is the MGC's responsibility to audit and
>>then take any appropriate action.  How does the MG know that the MGC doesn't
>>know about the contexts?  It doesn't, actually, and therefore cannot choose
>>to take it upon itself to clean up the contexts.
>>
>>For the second example, once again, it is the MGC's responsibility to audit
>>and take any appropriate action.  If it has a knowledge of the current
>>state, then that makes the process easier -- potentially eliminating the
>>audit step.
>>
>>The third case is similar to the first, except that the Disconnected method
>>should be used.  Other than this, the MGC has the responsibility to audit,
>>and take any appropriate action.
>>
>>By allowing the MG to automatically clean itself up without intervention
>>from the MGC, we would introduce many opportunities for the MGC and the MG
>>to get out of sync, leading to reduction of capacity and reliability.  The
>>MG should never take it upon itself to "clean itself up".  The MGC should be
>>designed such that it audits and takes appropriate action, or cleans up the
>>MG, if it chooses not to audit.
>>
>>Kevin
>>
>>-----Original Message-----
>>From: P.S.K. Chakravarthi [mailto:[email-masked]]
>>
>>    
>>
>>>hi
>>>   I have some doubts regading failure of MGC.
>>>
>>>oOo  case one:
>>>    Primary MGC failed when MG is in active state ( running state ) then
>>>      
>>>
>>MG detects peer failure and
>>    
>>
>>>try to connect to secondary MGC. But in this case new MGC doesn't know
>>>      
>>>
>>about the call contexts and all
>>    
>>
>>>activities happened in MG. In such a case what MG do..? should he cancel
>>>      
>>>
>>all active calls and start from
>>    
>>
>>>scratch or just maintain all the calls and whenever MGC request for audit
>>>      
>>>
>>give the details .. ?
>>Chak:
>>In this case MG should not cancel any context.
>>MG should even send the pending responses to the New MGC.
>>New MGC will accept the pending responses if
>>transaction level equalization is done between primary and secondary.  If
>>there is no transaction level equalization, then new MGC rejects the
>>responses (I mean MGC stack will not pass those responses to MGC
>>apllication) So MGC application after long timer will send SUBTRACT to
>>clear the contexts.
>>So in this there should be any problem for those calls which are not
>>having any pending responses from MG.
>>
>> >
>>    
>>
>>>oOo  case two:
>>>     Primary MGC wants MG to connect to a new MGC. In this case we can
>>>      
>>>
>>maintain all calls provided PrimMGC
>>    
>>
>>>passes all information related to the MG activities to new MGC and then
>>>      
>>>
>>relinquishes the control ...
>>    
>>
>>>( in that case what would be the protocol between primary MGC and directed
>>>      
>>>
>>MGC .. ? )
>>    
>>
>>>If this case works, what do we do with unresponded requests from MG .. do
>>>      
>>>
>>we need to expect the response
>>    
>>
>>>for them from new MGC or we need to drop all unresponded requests and send
>>>      
>>>
>>it again .. ?
>>Chak:
>>If you do not have transaction level equalization between primary and
>>secondary, you need to either drop the calls for which responses are
>>pending by sending SUBTRACT or re-transmit the requests from NEW MGC after
>>receiving SVC from MG.
>>    
>>
>>>oOo  case three :
>>>
>>>     Primary MGC goes down and secondary also is not reachable, and
>>>      
>>>
>>according to RFC we need to try all
>>    
>>
>>>possible listed MGC in a loop and the if we are able to connect to primary
>>>      
>>>
>>again, start conversation .. in
>>    
>>
>>>this case what do we so with the unresponded requests from the MGC before
>>>      
>>>
>>it goes down .. ?
>>Chak: In this case MG should send SVC with disconnected method.  After
>>receiving SVC MGC should AUDIT all the terminations and initiate necessary
>>clean-up.
>>
>>    
>>
>>>   What I feel is RFC doesn't talk about the state of the calls and other
>>>      
>>>
>>requests if MGC goes down and
>>    
>>
>>>connect to new MGC ...
>>>
>>>oOo
>>>   One more doubt is if a service change message is coming for ROOT
>>>      
>>>
>>termination, can that message contain
>>    
>>
>>>more some other transactions also .. ? or for the transaction which
>>>      
>>>
>>contains service change command for
>>    
>>
>>>ROOT termination contain more than one action .. ?
>>>      
>>>
>>Chak: Protocol does not limit this.  But I could not able to find any
>>usage for such a transaction.
>>    
>>
>>>
>>>
>>>_______________________________________________
>>>Megaco mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/megaco
>>>
>>>      
>>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>
>>_______________________________________________
>>Megaco mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/megaco
>>    
>>
>
>
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>  
>

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 12:30:54 -0400

--

---

From: Gunter Weiss <[email-masked]>
Date: Tue, 23 Jul 2002 17:38:49 +0200

Hello all,

first of all:
   ServiceChange message with “Disconnected” method!"

-- ,
Gunter

---

From: Gunter Weiss <[email-masked]>
Date: Tue, 23 Jul 2002 17:38:49 +0200

Hello all,

first of all:

-- ,
Gunter

---

From: Gunter Weiss <[email-masked]>
Date: Tue, 23 Jul 2002 19:33:09 +0200

Terry,
in all the implementors guides I could access (e.g. packetizer.com)
are stating about the second paragraph. My point is addressed in the
first paragraph.
But I found it in the
http://www.ietf.org/internet-drafts/draft-ietf-megaco-3015corr-01.txt

Could you point me to the "H.248.1 (the latest text for v1)" or is it the one
above??

See further inline.

Thanks, Gunter

> it just wants to find one that accepts it.

Well I ment only the SVCH method type not the fact as such!

> reason but perhaps 900 Service Restored

 I aggree on that although it's a bit missleading.
It's the most suitable of the today defined ones!
But this should force the MGC to Audit the MG. Or??
In far future I could imagine a "9xx - Reregistration attempt" in such a
scenario, where a SVCH (disconnected) leads still to 504 - unathorized.

--
                            Gunter Weiss,  VS/NGE,  VND
    +--------V--------+     Competance Area Leader - Gateway Protocols
    |  A L C A T E L  |     callto: +49-711-821-41613 faxto : .-40247
    +-----------------+     mailto:[email-masked]

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 12:30:11 -0500

This is why I ask the question regarding all these different Megaco version/drafts, IETF vs
ITU and
backward compatibility issues.

You can't go to the customer and tell them that my product is based on the "latest text for
v1" whatever
it might be or whatever draft version it is being worked on by whoever happens to be
working on it
at the time.

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

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Tue, 23 Jul 2002 12:30:11 -0500

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 14:20:29 -0400

The "in force" version of an ITU standard is the "latest" approved and 
published edition. (I am avoiding the use of "version" for the document 
as we usually associate "version" with protocol version, a number in our 
messages, which has no general meaning to ITU, document editions are 
designated only by a date). Even without changing the protocol version 
number or identifier a version may be officially amended.  The Study 
Group 16 community has usually considered that approved Implementors 
Guides (at each Study Group meeting approximately every 9 mo) also amend 
the current standard but this is not official ITU policy and this is the 
primary reason that H.248v1 was officially amended by the approval of 
H.248.1 by AAP procedures after the Feb 2002 SG16 meeting.  This text is 
now the official in force text of H.248v1.  Additional changes approved 
in future IGs are recommended for use but will not hold "in force" 
status until a newer edition of H.248.1 is approved.

IETF procedures are slightly different and perhaps Tom will want to 
restate them, but I believe that new text for H.248v1 would become 
official when a new RFC is issued based on the H.248.1 text and this has 
not yet been done for H.248v1.

Chuong N. Nguyen wrote:

>  
> This is why I ask the question regarding all these different Megaco 
> version/drafts, IETF vs ITU and
> You can't go to the customer and tell them that my product is based on 
> the "latest text for v1" whatever
> it might be or whatever draft version it is being worked on by whoever 
> happens to be working on it
> at the time.
>  
>  
>
> Terry L Anderson wrote:
>
>> Gunter Weiss wrote:
>>
>> >Hello all,
>> >
>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla> (Lucent 
>> internal) http://www.gti.net/tla
>>

--

---

From: Gunter Weiss <[email-masked]>
Date: Tue, 23 Jul 2002 19:33:09 +0200

Terry,

See further inline.

Thanks, Gunter

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 14:57:47 -0400

The first paragraph of 11.5 was amended by adding the last sentence:

    When contacting its previously controlling MGC the MG sends the 
ServiceChange message with "Disconnected" method.

by item 6.92 (which made other related changes to other parts of the 
spec).  The item was discussed on the mailing list in July of 2001 under 
the Subject: [Megaco] Failure of MGC. It first appeared in the draft IG 
at the Dublin Rapporteur's meeting in Oct/Nov 2001 (TD-28) but 
officially approved at the Feb 2002 SG16 meeting where all changes were 
swept into H.248.1 (and so no longer appeared in the IG).

>Could you point me to the "H.248.1 (the latest text for v1)" or is it the one
Normally the final editor's version should appear on the SG16 site:
    http://standard.pictel.com/ftp/avc-site/0202_Gen/
after the meeting, but I do not find it there.  I will ftp it to
    http://standard.pictel.com/ftp/avc-site/Incoming/pl-036r1_h248_1.zip
and ask it to me moved into 0202_Gen.  Note that this document is 
internally titled "Corrigendum 1 to Recommendation H.248" which was the 
original title.  It was changed to H.248.1 later in a general 
renumbering of H.248 related documents and will appear that way on the 
official ITU site.

An entry for it (but no link) appears on the packetizer site named: 
Corrigendum 1 to H.248v1 which was the original name.

I believe that this is the same text (converted to ASCII and formated as 
I-D) that Tom issued as draft-ietf-megaco-3015corr-01.txt.

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 14:57:47 -0400

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 23 Jul 2002 14:20:29 -0400

--