Subject: [Megaco] Restriction on Modification Of Terminations

From: Tom Taylor <[email-masked]>
Date: Tue, 15 Apr 2003 11:01:40 -0400

I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1) prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there is this 
sentence:

"An MGC can only release/modify Terminations
    and the resources that the Termination represents which it has
    previously seized via, e.g., the Add command."

It seems to me this precludes doing Modifies in the NULL context, but I've seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

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

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 15 Apr 2003 11:53:46 -0400

Clearly this is an error, since, for example, the MG wouldn't want a phone
in a context just to detect off-hook.  Likewise, if that set is currently in
Null and looking for off-hook, then the MGC may wish to stop looking for
off-hook (for any of a number of reasons) by Modifying the term with an
empty Events descriptor.

Any objections to striking the "/modify" portion of the sentence via the IG?

Kevin

-----Original Message-----
From: Taylor, Tom-PT [CAR:5N00:EXCH] 
Sent: Tuesday, April 15, 2003 11:02 AM
To: [email-masked]
Subject: [Megaco] Restriction on Modification Of Terminations

I've just been proof-reading the replacement for RFC 3015 (i.e. H.248.1 v1)
prior to 
its release, and got a slight surprise.  At the end of section 6.2.1 there
is this 
sentence:

It seems to me this precludes doing Modifies in the NULL context, but I've
seen 
various call flows that do just that.  Should we feed this back to SG 16 as 
something that should be fixed up to conform with practice?

Tom Taylor

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 15 Apr 2003 13:39:54 -0400

The argument can be made that the resources were previously seized via an
Add.  I will look back through some older IGs and see if I can find where
this came from...

Kevin

-----Original Message-----
From: Srinivasan Krishnamoorthy [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2003 1:34 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]
Subject: RE: [Megaco] Restriction on Modification Of Terminations

Hi,

What happens in the case where a Handoff to a redundant MGC has happened,
but the contexts where originally created by a 
primary MGC.

So, shouldn't we actually allow Subtracts from the new MGC,
as well then?

Thanks,
-Srini

On Tue, 15 Apr 2003, Kevin Boyle wrote:

kboyle>Clearly this is an error, since, for example, the MG wouldn't 
kboyle>want a phone in a context just to detect off-hook.  Likewise, if 
kboyle>that set is currently in Null and looking for off-hook, then the 
kboyle>MGC may wish to stop looking for off-hook (for any of a number of 
kboyle>reasons) by Modifying the term with an empty Events descriptor.
kboyle>
kboyle>Any objections to striking the "/modify" portion of the sentence 
kboyle>via the IG?
kboyle>
kboyle>Kevin
kboyle>
kboyle>-----Original Message-----
kboyle>From: Taylor, Tom-PT [CAR:5N00:EXCH]
kboyle>Sent: Tuesday, April 15, 2003 11:02 AM
kboyle>To: [email-masked]
kboyle>Subject: [Megaco] Restriction on Modification Of Terminations
kboyle>
kboyle>
kboyle>I've just been proof-reading the replacement for RFC 3015 (i.e. 
kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  At 
kboyle>the end of section 6.2.1 there is this
kboyle>sentence:
kboyle>
kboyle>"An MGC can only release/modify Terminations
kboyle>    and the resources that the Termination represents which it has
kboyle>    previously seized via, e.g., the Add command."
kboyle>
kboyle>It seems to me this precludes doing Modifies in the NULL context, 
kboyle>but I've seen various call flows that do just that.  Should we 
kboyle>feed this back to SG 16 as something that should be fixed up to 
kboyle>conform with practice?
kboyle>
kboyle>Tom Taylor
kboyle>
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>[email-masked] https://www1.ietf.org/mailman/listinfo/megaco
kboyle>_______________________________________________
kboyle>Megaco mailing list
kboyle>[email-masked]
kboyle>https://www1.ietf.org/mailman/listinfo/megaco
kboyle>

---

From: "Kevin Boyle" <[email-masked]>
Date: Wed, 23 Apr 2003 14:31:33 -0400

Since I haven't seen any objections to this wording, I will include it in
the IG for May's SG16 meeting.

Kevin

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2003 8:19 PM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]
Cc: [email-masked]; Taylor, Tom-PT [CAR:5N00:EXCH]; [email-masked]
Subject: Re: [Megaco] Restriction on Modification Of Terminations

G'Day Kevin,

The text has been there from way back when we determined H.248 version 1. It
seems noone has paid attention to it since then!!!

How about adding:
An MGC can only release/modify terminations and the resources that the
termination represents <<which are in the NULL context or>> which
>>delete:it has<< <<have been>> previously seized via, e.g., the Add
command.

The removal of "it has" should cover the servicechange concern.

Regards, Christian

Kevin Boyle wrote:
> 
> The argument can be made that the resources were previously seized via 
> an Add.  I will look back through some older IGs and see if I can find 
> where this came from...
> 
> Kevin
> 
> What happens in the case where a Handoff to a redundant MGC has 
> happened, but the contexts where originally created by a primary MGC.
> 
> So, shouldn't we actually allow Subtracts from the new MGC, as well 
> then?
> 
> Thanks,
> -Srini
> 
> kboyle>want a phone in a context just to detect off-hook.  Likewise, 
> kboyle>if that set is currently in Null and looking for off-hook, then 
> kboyle>the MGC may wish to stop looking for off-hook (for any of a 
> kboyle>number of
> kboyle>Any objections to striking the "/modify" portion of the 
> kboyle>sentence via the IG?
> kboyle>
> kboyle>Kevin
> kboyle>
> kboyle>H.248.1 v1) prior to its release, and got a slight surprise.  
> kboyle>At the end of section 6.2.1 there is this
> kboyle>sentence:
> kboyle>
> kboyle>It seems to me this precludes doing Modifies in the NULL 
> kboyle>context, but I've seen various call flows that do just that.  
> kboyle>Should we feed this back to SG 16 as something that should be 
> kboyle>fixed up to conform with practice?
> kboyle>
> kboyle>Tom Taylor
> kboyle>