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

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

Hello Annie,

I guess I have the question why would you re-negotiate the profile and 
H.248 version when you want to maintain state on the MG? or are you 
trying to find the already negotiated profile and protocol versions?

A solution is for the MGC to send a Service Change Restart with Reason 
902 Warm Boot (check H.248.8 which says 902 indicates that state is 
maintained). e.g. H.248.1v3 Annex F.3.9 has MGC Initiated Service 
Restoration this then points to F.3.2 MG Re-Registration which provides 
for profile and protocol negotiation.

For those referring to H.248.1v2, Annex F is equally applicable for 
those procedures also. Annex F was produced to clarify the servicechange 
procedures and in itself does not add any new functionality.

Regards, Christian

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

---

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Wed, 6 Dec 2006 20:17:28 -0500

Hi Christian,

See below: 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 8:14 PM
To: Annie Benitez Pelaez
Cc: [email-masked]
Subject: Re: [Megaco] Version/Profile Re-Negotiation

Hello Annie,

I guess I have the question why would you re-negotiate the profile and
H.248 version when you want to maintain state on the MG? or are you trying
to find the already negotiated profile and protocol versions?

>> the latter. I guess it's a bit of a rare case, but say MGC rebooted and
doesn't remember the version or packages on the MG.

A solution is for the MGC to send a Service Change Restart with Reason
902 Warm Boot (check H.248.8 which says 902 indicates that state is
maintained). e.g. H.248.1v3 Annex F.3.9 has MGC Initiated Service
Restoration this then points to F.3.2 MG Re-Registration which provides for
profile and protocol negotiation.

>> Yes I thought about that one, but the fact that you're calling it a "warm
boot" may also imply that other things may get re-started... It would work I
agree, but it seems a bit vague don't you think? ... That's why I was
thinking of a specific reason code somethinf of the like "version
re-negotiation"... As far as packages that's an easy once since the MGc can
always audit them again.

Thanks!!
Annie

For those referring to H.248.1v2, Annex F is equally applicable for those
procedures also. Annex F was produced to clarify the servicechange
procedures and in itself does not add any new functionality.

Regards, Christian

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?
>
>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...)
>

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 6 Dec 2006 20:41:41 -0500

The need to renegotiate profile/version may occur due to an InService
upgrade of the MG.  In this instance, the MG can send a SC Restart on
Root with Reason 917, "Capabilities Change".  This could lead to a
renegotiation of the protocol version and profile if those parameters
are included in the SC command.

Kevin 

-----Original Message-----
From: Annie Benitez Pelaez [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 8:17 PM
To: 'Christian Groves'
Cc: [email-masked]
Subject: RE: [Megaco] Version/Profile Re-Negotiation

Hi Christian,

See below: 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Wednesday, December 06, 2006 8:14 PM
To: Annie Benitez Pelaez
Cc: [email-masked]
Subject: Re: [Megaco] Version/Profile Re-Negotiation

Hello Annie,

>> Yes I thought about that one, but the fact that you're calling it a 
boot" may also imply that other things may get re-started... It would
work I agree, but it seems a bit vague don't you think? ... That's why I
was thinking of a specific reason code somethinf of the like "version
re-negotiation"... As far as packages that's an easy once since the MGc
can always audit them again.

Thanks!!
Annie

Regards, Christian

---

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

G'Day Annie,

902 was developed specifically for the case where state is maintained 
due to a restart. e.g.

*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 states are preserved on the termination.

If your MGC has actually failed and restarted then I think that 
"restart" is the applicable method. If we introduce a new reason code 
what impact would that have on state? How would you describe this?

I agree packages are easy to audit. Profile is not so easy to simply 
audit (unless you support H.248.18).

Regards, Christian

---

From: "Annie Benitez Pelaez" <[email-masked]>
Date: Wed, 6 Dec 2006 20:51:46 -0500

Good point, 902 would work.. And then I would assume that all events would continue to remain enabled and so on.
The only thing that would occur would be that any interfaces that are OOS would need to be reported to be OOS again by the MG.

And the only caveat as well is that that ServiceChange Restart/902 MGC->MG would probably need to be encoded in V1 to be on the safe side.

Thanks,
Annie

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, December 06, 2006 8:42 PM
To: Annie Benitez Pelaez
Cc: [email-masked]
Subject: Re: [Megaco] Version/Profile Re-Negotiation

G'Day Annie,

902 was developed specifically for the case where state is maintained due to a restart. e.g.

*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 states are preserved on the termination.

If your MGC has actually failed and restarted then I think that "restart" is the applicable method. If we introduce a new reason code what impact would that have on state? How would you describe this?

I agree packages are easy to audit. Profile is not so easy to simply audit (unless you support H.248.18).

Regards, Christian

Annie Benitez Pelaez wrote:

>work I agree, but it seems a bit vague don't you think? ... That's why 
>I was thinking of a specific reason code somethinf of the like "version 
>those procedures also. Annex F was produced to clarify the 
>servicechange procedures and in itself does not add any new functionality.
>
>Regards, Christian
>