Subject: Re: [Megaco] Version/Profile Re-Negotiation

From: Carsten Waitzmann <[email-masked]>
Date: Fri, 01 Dec 2006 14:38:51 +0100

Ashish,

looking to H.248.1v3 Annex F.3.1, I think it is said that in case of "failover" 
and "handoff" the previous control association is terminated and a new control 
association is to be setup. So I don't see the option to keep alive the control 
association in this case.

Annie,
H.248.1v3 Annex F.3.8 talks about "MGC initiated MG re-registartion". Couldn't 
that be a mean for the MGC to request MG re-registration?

best regards
Carsten

Ashish Singh wrote:

> Annie,
> 
> Even Handoff and Failover doesn't really start a new control 
> association, but H.248.1 recommends to do version negotiation in those 
> case. So I think disconnected should also be treated in similar way.
> 
> Regards
> Ashish
> 
> 
> 
> Annie Benitez Pelaez wrote:
> 
>> Ashish/Raju,
>>
>> Thanks for your responses...
>>
>> I guess since the MG will never know when the MGC may have been rebooted
>> (vs. simple a timeout on the H248 control interface for say a link 
>> failure
>> for example) then is it expected that those Disconnected messages are
>> encoded in Version 1 and include Version Negotiation in the Service 
>> Change
>> command..?
>>
>> Since a Disconnected isn't really starting a new control association (in
>> theory), that's why it seems a bit odd to me I suppose, but I see no 
>> other
>> way around it...
>>
>> Thx,
>> Annie
>>
>>
>> -----Original Message-----
>> From: Ashish Singh [mailto:[email-masked]] Sent: Thursday, 
>> November 30, 2006 3:24 PM
>> To: Annie Benitez Pelaez
>> Cc: [email-masked]
>> Subject: Re: [Megaco] Version/Profile Re-Negotiation
>>
>> Version negotiation is optional in Servicechange message with 
>> Disconnected
>> method. So I think MG can send version and profile field even in
>> Disconnected case and do version negotiation.
>>
>> I am giving an example where doing version negotiation is useful in
>> disconnected case. Let say MGC-1 goes down and comes up with higher 
>> version.
>> In that case, MGC1 would expect version negotiation even if its the 
>> same MGC
>> instance.
>>
>> Thanks
>> Ashish
>>
>>
>> Annie Benitez Pelaez wrote:
>>  
>>
>>> All,
>>>
>>> Is there a way to re-start both profile and H.248 version negotiation 
>>> on an existing H.248 control association?
>>>
>>> Allow me to explain further the particular case I had in mind...
>>>
>>> Let there be a succesful H.248 control association established 
>>> between MGC-1 and MG-1 (say they negotiated to version 2).
>>> Let MGC-1 restart.
>>>
>>> Therefore MG-1 may notify an inactivity timeout event, that message 
>>> will fail to be responded (since MGC-1 is restarting), then MG-1 will 
>>> continue to try to send ServiceChange with Disconnected Method 
>>> (assuming there's no secondary MGC configured here).
>>>
>>> Once MGC-1 restarts, MGC-1 gets the ServiceChange Disconnected from 
>>> MG-1 (encoded in v2 since that was previously negotiated).
>>>
>>> So at this point is there a way for MGC-1 to initialized profile and 
>>> version negotiation? And if so how? (one way would be to have the MGC 
>>> send down a restart to the MG, but let's assume we don't want to 
>>> clear any state on the
>>> MG...)
>>>
>>> I'd appreciate your thoughts on this one...
>>> Thanks!
>>>
>>> Annie
>>>
>>>
>>>
>>> _______________________________________________
>>> 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

---

From: Carsten Waitzmann <[email-masked]>
Date: Fri, 01 Dec 2006 14:21:39 +0100

Ashish,

Annie,

best regards
Carsten

---

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Fri, 1 Dec 2006 11:59:33 -0500

Yes Carsten, I believe the HandOff in F.3.8 is probably the right place to
do it at (even though you're not really handing off)... Another option would
be to have the MGC send a Restart to the MG (potentially with a "Warm Boot"
or maybe even a new reason code may be in order...)

-----Original Message-----
From: Carsten Waitzmann [mailto:[email-masked]] 
Sent: Friday, December 01, 2006 8:39 AM
To: Ashish Singh
Cc: Annie Benitez Pelaez; 'Maridi Raju Makaraju(Raju)'; [email-masked]
Subject: Re: [Megaco] Version/Profile Re-Negotiation

Ashish,

looking to H.248.1v3 Annex F.3.1, I think it is said that in case of
"failover" 
and "handoff" the previous control association is terminated and a new
control association is to be setup. So I don't see the option to keep alive
the control association in this case.

Annie,
H.248.1v3 Annex F.3.8 talks about "MGC initiated MG re-registartion".
Couldn't that be a mean for the MGC to request MG re-registration?

best regards
Carsten

Ashish Singh wrote:

>> I guess since the MG will never know when the MGC may have been 
>> rebooted (vs. simple a timeout on the H248 control interface for say 
>> a link failure for example) then is it expected that those 
>> Disconnected messages are encoded in Version 1 and include Version 
>> Negotiation in the Service Change command..?
>>
>> Since a Disconnected isn't really starting a new control association 
>> (in theory), that's why it seems a bit odd to me I suppose, but I see 
>> no other way around it...
>>
>> Thx,
>> Annie
>>
>>
>> Disconnected method. So I think MG can send version and profile field 
>> even in Disconnected case and do version negotiation.
>>
>> same MGC instance.
>>> Is there a way to re-start both profile and H.248 version 
>>> negotiation on an existing H.248 control association?
>>>
>>> will fail to be responded (since MGC-1 is restarting), then MG-1 
>>> will continue to try to send ServiceChange with Disconnected Method 
>>> version negotiation? And if so how? (one way would be to have the 
>>> MGC send down a restart to the MG, but let's assume we don't want to 
>>> clear any state on the
>>> MG...)
>>>

---

From: "Maridi Raju Makaraju\(Raju\)" <[email-masked]>
Date: Fri, 1 Dec 2006 14:14:37 -0600

Annie, Ashish, Carsten,

Spec says any ROOT Service Change with all methods except Forced
initiates Registration with MGC.
Each Registration process, irrespective of method, should do the
following:
1. Send the Service Change using Version 1. This is to handle
   the case where the MGC has gone thru a downgrade (or a failed 
   upgrade) and using a lower version than negotiated earlier. 
   In such a case the method used is Disconnected.
2. Version negotiation
3. Profile info in the Service Change method

Thanks
Raju

> Sent: Friday, December 01, 2006 7:39 AM
> To: Ashish Singh

---

From: [email-masked]
Date: Mon, 4 Dec 2006 08:15:51 +0100

Raju,
just a question for clarification:
Definitive reference for all ServiceChange related questions is H.248.1 V3,
in particular Annex F.
Thus, "Spec says ..." means V3 text? If yes, do you refer to § F.4.1.1?

(The 1st SC command.request is sent by the MGC here in this discussion.
Therefore "Disconnected" is another exception, because may only sent by
MG).

Best regards,
Albrecht

                      mmraju@alcatel-l                                                                                                
                      ucent.com                To:      "Carsten Waitzmann" <[email-masked]>, "Ashish Singh"            
                                               <[email-masked]>, "Annie Benitez Pelaez" <[email-masked]>                
                      01.12.2006 21:14         cc:      [email-masked]                                                               
                                               Subject: RE: [Megaco] Version/Profile Re-Negotiation                                   

Annie, Ashish, Carsten,

Thanks
Raju

"failover"
> and "handoff" the previous control association is terminated and a new
control
> H.248.1v3 Annex F.3.8 talks about "MGC initiated MG re-registartion".
Couldn't
> >> I guess since the MG will never know when the MGC may have been
rebooted
> >> Since a Disconnected isn't really starting a new control association
(in

---

From: "Raphael Tryster" <[email-masked]>
Date: Mon, 4 Dec 2006 11:28:14 +0200

According to the ABNF,

Version = 1*2(DIGIT)

I didn't catch it when I reviewed T.38 Appendix III last year, but the
examples in it give "MEGACO/1.0" in the header, and a few emails in this
list have also included a decimal point in the version.

This looks like an error.  Are there real implementations that add the
decimal point?  If so, then I guess that "be strict in what you send,
loose in what you accept" applies.  

Raphael Tryster
**********************************************************************************************
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: "Maridi Raju Makaraju\(Raju\)" <[email-masked]>
Date: Mon, 4 Dec 2006 13:26:10 -0600

Albrecht,

I am referring to the H.248 version 2 spec from ITU.
Here is what I sent in my initial response to Annie. From the text
I am convinced that any Service Change on ROOT expect Forced completes registration
and for any registration Version negotiation and profile exchange has to be done.

============ Text from my earlier response - Begin===========
Any Initial Service Change on ROOT with which MG announces it's availability
is considered as "Registration". So, the all ROOT service change methods except
Forced should be considered as part of registration.

Section 7 of version 2 spec says:
================
8) ServiceChange: The ServiceChange command allows the Media Gateway to notify the
Media Gateway Controller that a Termination or group of Terminations is about to be taken
out of service or has just been returned to service. ServiceChange is also used by the MG to
announce its availability to a MGC (registration), and to notify the MGC of impending or
completed restart of the MG.
================
============ Text from my earlier response - End===========

Thanks
Raju

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 04, 2006 1:16 AM
To: [email-masked]
Cc: [email-masked]; Carsten Waitzmann
Subject: RE: [Megaco] Version/Profile Re-Negotiation

Raju,

Best regards,
Albrecht

                      mmraju@alcatel-l

Annie, Ashish, Carsten,

Thanks
Raju

"failover"
control
Couldn't
rebooted
(in

---

From: "John Wainwright" <[email-masked]>
Date: Mon, 4 Dec 2006 16:40:22 -0600

Does anyone have an example of the format of the information contained
in the 
	andisp/data {db=???} 

field for an AoC and an SMS type message

Thanks
John

---

From: Manuel Poza <[email-masked]>
Date: Tue, 05 Dec 2006 12:50:19 +0100

Hi, John

The format is:

message type + message length + presentation layer message + checksum

The presentation layer include parameters with the format: type + length 
+ data.

In Table B.1 of ETSI document EN 300 659-3 you can find the list of 
parameters applicable to AoC and SMS services. In sub-clause 5.4 of the 
same document, you can find the codification of the parameters.

Regards,

Manuel

---

From: Christian Groves <[email-masked]>
Date: Thu, 07 Dec 2006 12:28:46 +1100

G'Day Raphael,

Yes this is an an error. The ABNF and ASN.1 encodings don't support the 
use of  the decimal point. It's also clear from notes in the encodings 
e.g.:     
-- The version of the protocol defined here is equal to 3

 I too am guilty not catching it during the review of T.38. I'll make a 
note of this for input to the next SG16 meeting.

Regards, Christian

---

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 10 Dec 2006 10:44:19 +0200

According to ABNF, the correct spellings are "ReservedGroup" and
"ReservedValue", with a letter "d", and the valid values are "ON" and
"OFF".  Text in the standard and several examples in this list have
spelled the words without the "d" and used values "True" and "False".
This is another thing I didn't catch in the T.38 document.

Are "ReserveGroup", "ReserveValue", "True" and "False" legitimate
alternatives or errors?

Raphael Tryster

---

From: [email-masked]
Date: Mon, 11 Dec 2006 09:20:33 +0100

=> "Error" in text encoding.

The issue behind are different variable names in ASN.1 and ABNF syntax:
ASN.1             ABNF
reserveValue      vs ReservedValue
reserveGroup      vs ReservedGroup
True              vs ON
False             vs OFF

Thus, the semantical description in the main body of H.248.1 may use both
terminology and is not consistent at all places. But this is more
historical, - a matter of fact of support of two encoding schemes. This is
a very minor problem because in the end is the syntax definitive. We need
volunteers and correspondent contributions for the IMG in order to make the
text 100% consistent.

Albrecht

                      "Raphael Tryster"                                                                                                  
                      <raphael.tryster@vo         To:      <[email-masked]>                                                             
                      caltec.com>                 cc:                                                                                    
                                                  Subject: [Megaco] Reserve group & value syntax                                         
                      10.12.2006 09:44                                                                                                   

Raphael Tryster

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: "Raphael Tryster" <[email-masked]>
Date: Wed, 13 Dec 2006 17:39:03 +0200

" Within a context, StreamID is a means by which to indicate which media
flows are interconnected: streams with the same StreamID are connected".

Does this mean that if a physical and an ephemeral termination are added
to a context, and only the ephemeral termination has a media descriptor,
no media will be passed between them?

Here is an example from the T.38 document (where else...?):

MEGACO/1 [123.123.123.4]:55555
Transaction = 11 {
  Context = $ {
    Add = DS0/1/1 {
      Events = 1 {al/on, ctyp/dtone }
        },  ; SCN termination prepared to listen for tones
    Add = $ {
      Media { 
        Stream = 1 { 
          LocalControl { Mode=ReceiveOnly, ReservedGroup=On,
ReservedValue=On},
          Local {
v=0
c=IN IP4 $
m=audio $ RTP/AVP 18 0
v=0
c=IN IP4 $
m=image $ udptl t38
           }; IP termination for audio     
         }                  
       }
     }    
  }
}  
 
In the call flow examples in H.248 itself, physical terminations are
also added to contexts without a media descriptor being specified in
that command, but it was specified in earlier commands.  In the four
Megaco call flows given in the T.38 document, physical port DS0/1/1
never gets a media descriptor in two of them, and in one of them it gets
it after it is added to the context.

Is this another error in the T.38 document?  Are there any scenarios in
which it would be useful to add a termination to a context without a
media descriptor?

Raphael Tryster