Subject: Re: Can MGC modify term in NULL Context ?

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 13 Sep 2000 07:12:39 -0400

Resonses marked by [PTT].

> -----Original Message-----
> From: Kapil Nayar [mailto:[email-masked]]
> Sent: Wednesday, September 13, 2000 1:10 AM
> To: [email-masked]
> Subject: Re: Can MGC modify term in NULL Context ?
>
>
> Hi Tom, Brian
>
> Some confusion is ensuing from the replies......
>
> Do we have a consensus about the following:
> 1.   Default values are values specified in the packages.
[PTT] In the packages, and sometimes in the main protocol document.

> 2.   Provisioned values are values configured at MG end.
[PTT] Right.

>
> AND
> that we have two options do decide from
>
> Option 1
> MGC when modifies termination properties in the NULL context,
> changes the
> default/ provisioned values.
> These changes would be made to the package properties
> associated with the
> termination only.
[PTT] No. We got rid of that in Geneva (I guess, based on Brian's detective
work).  I may be fuzzy about exactly when, but I can tell you why: you could
get nonsensical results.  In particular, events and signals set up in the
NULL context BEFORE connecting the call would probably make no sense at all
once the connection is dissolved.

> If yes the following questions still remain unanswered:
> Do we allow provisioning of the termination properties after
> MGC modifies them
> in the NULL context.?
> If yes then how does MGC know about this asynchronous change
> ? This is because
> if MGC doesn't know about the change there is no sanctity of
> the changes made by
> the MGC. (One solution presented was that provisioning should
> be followed by a
> service change)
>
> Option 2
> MGC when modifies termination properties in the NULL context,
> changes the
> default/ provisioned values only temporarily. When the
> termination returns to
> the NULL context, default/ provisioned values are restored.
[PTT] That's how the document reads now.

> If yes the following questions still remain unanswered:
> Do we assume that MGC would audit the properties whenever it
> establishes an
> association with a MG and store a copy of the default/
> provisioned values. And,
> explicitly send modify for termination properties whenever it
> needs to change
> the termination property values.
[PTT] That's a workable strategy.

> Do we allow provisioning of the termination properties at run-time?
> If yes then how does MGC know about this asynchronous change
> ? This is because
> if MGC doesn't know about the change there is no sanctity of
> the audited values
> stored by MGC. (One solution presented was that provisioning
> should be followed
> by a service change)
[PTT] I think the service change would be a good idea.  We should look at
putting this into the Implementor's Guide if it doesn't contradict anything
already in the spec.

>
> Option 1 seems to be more appropriate, but the unanswered
> questions need to be
> appropriately addressed. We would like to have others views on this.
>
> -Kapil Nayar
> Hughes Software Systems Ltd.
>
>...
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 14 Sep 2000 11:17:25 +1100

G'Day all,

With regards to the service change idea there was a contribution to the
Portland SG16 meeting for H248v2 to add "ServiceChange => Capability
Change" as an indication that something (property, signal, event etc)
has changed on the MG and that the MGc should do an audit of what was
indicated in the service change to find out the exact change.

With regards to option 1 I did like the idea of the MGC being able to
change properties in the NULL context and make them stick but then we
have a mismatch between Physical and Euphemeral terminations as you
wouldn't have the same ability for the MGC to make changes stick.

Cheers, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 13 Sep 2000 23:02:20 -0400

Question for clarification here:

Exactly what is H.248v2 and who is working on it ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Sep 2000 21:48:09 -0400

The ink is barely dry on v1 and we all went through tremendous efforts to ensure that
the IETF and ITU-T would develop a single protocol. Am I to understand it was a wasted
effort as there now will be two protocols after all ? Where does this leave Megaco ?

-- Flemming

Christian Groves wrote:

> G'Day Flemming,
>
> Its the version after H.248v1 and SG16 are working on it.
>
> Cheers, Christian
>
> Flemming Andreasen wrote:
> >

--
Flemming Andreasen
Cisco Systems

---

From: Christian Groves <[email-masked]>
Date: Tue, 19 Sep 2000 06:29:16 +1100

G'Day Flemming,

No there will be one protocol(H.248, Megaco) with 2 versions. Version 2
following version 1. Version 2 work is just starting and will go
probably for another year thus giving "the ink" plenty of time to dry
before we have version 2 ready. No body has been from giving input to
this work.

Regards, Christian

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 19 Sep 2000 11:00:19 -0400

> before we have version 2 ready. No body has been from giving input to

I'm having a hard time following this logic. As we gain experience with v1, the IETF
presumably will want to advance it to Draft and Internet standard, yet meanwhile the ITU
will work on a successor, without the involvement of the IETF. Thus, for all practical
purposes, you have just declared the joint v1 protocol an interim ITU-T solution as they
move along on their own with v2. Maybe our WG chair or AD can clarify what the point with
the cooperation was and where that leaves Megaco v1 as compared to H.248v2 ?

Thanks

        Flemming

> > > > Exactly what is H.248v2 and who is working on it ?

<snip>

--
Flemming Andreasen
Cisco Systems

---

From: Christian Groves <[email-masked]>
Date: Wed, 20 Sep 2000 18:01:00 +1100

G'Day Flemming,

I don't see why you have a hard time following this logic.

The work on H248v2 has just started. No one has been excluded from this,
especially the IETF. The Working Group Chair was at the SG16 meeting
where this occured. I believe that its a decision for the IETF if it
wants to be involved. I gather some sort of charter change would be
required.

We have probably at least 14 months before we decide on H248v2 so there
is plenty of scope for other parties to be involved and the logistics of
this involvement sorted out.

Regards, Christian

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Sep 2000 09:44:26 -0700

One basic problem is that IETF doesn't have "versions"
per se. In the same period of time, the current proposed
standard should be advancing to draft standard with
the normal IETF'ism of deleting unused features, etc,
etc. Unless a proposed standard recycles itself back
as a new proposed standard, there is no way to add a
bunch of new features, etc.

If SG16 goes off and creates a new version which is
not using the same criteria, something has got to
give: either MEGACO and SG16 keep cooperating such
that both produce a standard which will become a
full IETF internet standard, or they diverge.

I share Flemming's concern here. Without a great
deal of explict understanding and resolution of
how both IETF and ITU processes can be
simultaneously satisfied (and there are challenges
on the IETF side as well), the end result will
be divergence which would have made this entire
joint effort mostly a waste.

             Mike