Subject: RE: [Megaco] A new problem : should the signal be stopped after s ubtract(with no signal discriptor)

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 21 Apr 2005 10:28:19 -0400

Comments inline. [KJBII]
 
Kevin

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, April 21, 2005 4:29 AM
To: [email-masked]
Subject: [Megaco] A new problem : should the signal be stopped after
subtract(with no signal discriptor)

Hello: 
    
   This days we come across a problem: 

      1, physical terminate agw0 is in context 1 ,and it is onhook and it is
playing ring-signal 
      2, MGC send a subtract cmd to delete the physical terminate to NULL
context , 
         but there is no signal discriptor in the cmd : 
         !/1 [10.29.60.81]:2944 
          T=1{ 
            C=1{S=*} 
             } 

[KJBII] Signal descriptors can never be present in a Subtract command.
 
      3, should the signal be stopped? 

[KJBII] Yes. 

  In Rfc 3525 7.1.11  at the end of page[53]   The subtract cmd is
descripted as follow:   
 
[KJBII] Subtract is defined in Section 7.2.3, not 7.1.11 which is the
section for the Signals descriptor. 
  
   When a provisioned Termination is Subtracted from a Context, its 
   property values shall revert to: 

   -  the default value, if specified for the property and not 
      overridden by provisioning; 
   -  otherwise, the provisioned value. 
[KJBII] In this context, this use of "property" actually refers to the
descriptors.  So the Signals descriptor would revert to its default value. 
  
  but We do not know whether signal is a property of a termination? 
  And there is no definition in Rfc 3525 about this  (may be we have not
found it yet) 

   In Rfc 3525  7.1.11 page[38]   there presents 4 conditions when a signal
is stopped: 

  Finally, the optional parameter "notifyCompletion" allows a MGC to 
   indicate that it wishes to be notified when the signal finishes 
   playout. The possible cases are   
(1)that the signal timed out (or otherwise completed on its own), 
(2)that it was interrupted by an event, 
(3)that it was halted when a Signals descriptor was replaced, 
(4)or that it stopped or never started for other reasons. 
   If the notifyCompletion parameter is not included in a Signals
descriptor, notification is 
   generated only if the signal stopped or was never started for other
reasons. 

[KJBII] These four cases apply specifically to the generation of
notification for a stopped signal, and are not an attempt to explicitly
enumerate the scenarios in which a signal will halt.  That being said,
"other reasons" would certainly apply in the case you describe. 

  It seems to be that "subtract" cmd with no "signal  discriptor" do not
belongs to the upper 4 cases. 
  Then the signal should not be stopped  . 
  
  Is it Right? Alcatel's Engineers seems to have different opinions . Please
give us a reply ! We are confused about This.
[KJBII] The signal should be halted. 

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

---

From: "Gillian Wang" <[email-masked]>
Date: Tue, 26 Apr 2005 17:19:30 +1000

Hi all,

Section 11.3 of H.248.1 provides a method of version negotiation in
ServiceChange command. But the example call flows show a simple way without
version negotiation.

My question is:

Is this ServiceChangeVersion parameter mandatory in the MG REGISTRATION
time? If no ServiceChangeVersion indicated in the serviceChange command from
MG (as the example does in Appendix I), what should MGC do? Suppose that MGC
can support the version indicated in the message header (MEGACO/2 [....])?
Follow the version received from the header of serviceChange command or
report an error?

Thanks for the clarifications.

Regards
Gillian

---

From: [email-masked]
Date: Wed, 27 Apr 2005 13:10:54 +0530

Hi,

H.248.1  v2  Corrigendum  1  (03/2004) has service change version parameter
present in the service change request in example call flow.

       "1)   An MG registers with an MGC using the ServiceChange command:

     MG1 to MGC:

     MEGACO/1 [124.124.124.222]
     Transaction = 9998 {
         Context = - {
             ServiceChange = ROOT {Services {
                 Method=Restart, Version=2,
                 ServiceChangeAddress=55555, Profile=ResGW/1}
             }
         }
     }"

Following is an extract from H.248.1 (05/2002).
      "11.3 Negotiation of protocol version

       A  ServiceChange  command from a MG that registers with an MGC shall
contain the version

       number    of   the   protocol   supported   by   the   MG   in   the
ServiceChangeVersion parameter. Regardless of

       the  version  placed  in  the  ServiceChangeVersion  parameter,  the
message containing the command

       shall be encoded as a version 1 message."

It makes service change version in the first service change request
mandatory. And message header will contain version 1 here regardless of
service change version parameter. If the MGC receives registration message
with Megaco message header 2 or service change version parameter absent,
then the MGC should report protocol error.

-------------------------------------------------

How ever there is another discrepancy in the ABNF specification of
protocol. It should not make service change version mandatory on the first
service change response.

Fllowing is extract of H.248.1 v2 Corrigendum 1 (03/2004) (B.2    ABNF
specification).
     "; at-most-once. Version is REQUIRED on first ServiceChange response
     ; at most one of either serviceChangeAddress or serviceChangeMgcId but
     ; not both
     servChgReplyParm     = (serviceChangeAddress / serviceChangeMgcId /
                            serviceChangeProfile / serviceChangeVersion /
                            TimeStamp)"

It implies that version is required in the first service change response.
But neither H.248.1 (05/2002) nor H.248.1 v2 Corrigendum 1 (03/2004)
contain the version in service change reply.

       "2)   The MGC sends a reply:

     MGC to MG1:
     MEGACO/1 [123.123.123.4]:55555
     Reply = 9998 {
        Context = - {ServiceChange = ROOT {
          Services {ServiceChangeAddress=55555, Profile=ResGW/1} } }
     }"

and H.248.1 v2 Corrigendum 1 (03/2004) section 11.3 indicates that service
change version is optional in first service change reply from MGC.
Following is extract of H.248.1 v2 Corrigendum 1 (03/2004)
      "If the MGC supports the version indicated by the MG, it shall
conform to that version in all
      subsequent messages. In this case, it is optional for the MGC to
return a version in the
      ServiceChangeReply."

Regards,
Sudhanshu
Flextronics Software Systems
www.hssworld.com

"Gillian Wang" <[email-masked]>@ietf.org on 04/26/2005 12:49:30 PM

Sent by:    [email-masked]

To:    <[email-masked]>
cc:

Subject:    [Megaco] Version negotiation

Hi all,

My question is:

Is this ServiceChangeVersion parameter mandatory in the MG REGISTRATION
time? If no ServiceChangeVersion indicated in the serviceChange command
from
MG (as the example does in Appendix I), what should MGC do? Suppose that
MGC
can support the version indicated in the message header (MEGACO/2 [....])?
Follow the version received from the header of serviceChange command or
report an error?

Regards
Gillian

_______________________________________________
Megaco mailing list
[email-masked]
 https://www1.ietf.org/mailman/listinfo/megaco
 IMPORTANT: HUGHES SOFTWARE SYSTEMS LTD. (HSS) IS NOW FLEXTRONICS SOFTWARE
 SYSTEMS LTD. (FSS)

 *****************    FSS-Private    *************

"DISCLAIMER: This message is proprietary to Flextronics Software 
Systems Limited (FSS) and is intended solely for the use of the  
individual to whom it is addressed. It may contain  privileged or 
confidential information and should not be circulated or used for 
any purpose other than for what it is intended. If you have received 
this message in  error, please notify the originator immediately. 
If you are not the intended recipient, you are notified that you are
strictly  prohibited  from  using, copying, altering, or disclosing
the contents of this message.  FSS  accepts no  responsibility  for
loss or damage arising from the use of  the information transmitted
by this email including damage from virus."