Subject: [Megaco] Emergency/Priority indicators

From: "Miri Epstein" <[email-masked]>
Date: Thu, 21 Feb 2008 14:00:39 -0000

Hi,

I have some questions regarding the emergency and priority context
attributes:

1/ Assuming, for example, that a context was created by an Add command
with priority=5. Then a Modify command is issued by MGC with priority=7.
Does this mean that the context priority is changed to 7?

2/ Assuming, for example, that a context was created by an Add command
with the emergency indicator (emergency is ON). A consequent Modify
command omitting the emergency indicator is issued by the MGC. Does it
mean that this specific context is not anymore an emergency context?

3/ Are these scenarios of modifying the context attributes reasonable?
Or, is it expected that a specific priority level set to a context will
not be changed until the context ceases?
    
Thanks for your help,
Miri

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 22 Feb 2008 10:10:08 +1100

Hello Miri,

Please see my replies below [CNG].

Regards, Christian

> Does this mean that the context priority is changed to 7?
[CNG] Yes the priority would be 7.
> mean that this specific context is not anymore an emergency context?
[CNG] If a Context property is omitted then it retains the previous 
setting. So it would remain on.
> not be changed until the context ceases?
[CNG] I would imagine that in most cases the priority would not be 
changed once the call/connection is established.

---

From: [email-masked]
Date: Thu, 21 Feb 2008 17:20:39 -0600

Hi,

I have question regarding segmentation response.

Receiver of a segment replies with the segementResponse that includes
the transaction-id and segment-number. 

But what is the purpose of this response, the sender procedure is not
defined on receipt of this response or say if the segmentation-response
gets lost?

Thanks,

Chai.

---

From: "Miri Epstein" <[email-masked]>
Date: Mon, 25 Feb 2008 07:28:54 -0000

Hello Christian,

ThanKs for your response.

About your answer to question 2/:

I couldn't find any explicit reference to that issue in the standard. Am
I missing it? If not, do you think this should go into the implementor's
guide?

It appears to me that the reason special handling is needed is because
the emergency, priority and topology properties are unique in not being
part of a descriptor. This could have been solved if they were migrated
to the ContextAttribute descriptor. Does this seem like something that
can be considered for H.248v4? I know that because of backward
compatibility, the current mode of operation will always be there, but
at least it could be deprecated.

Thanks,
Miri

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Friday, February 22, 2008 1:10 AM
To: Miri Epstein
Cc: [email-masked]; Shaikh, Viqar A. [RA]
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Miri,

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 26 Feb 2008 14:59:21 +1100

Hello Miri,

In H.248.1v3 Amm.1 we included the following in clause 6.1.1 to make the 
behaviour clear:
"In general, if a context attribute is completely omitted from a H.248 
action, the attribute of the corresponding context retains its prior value."

With regards to the "special handling" I'm not sure what you mean? What 
would you propose for H.248.1v4?

Regards, Christian

Miri Epstein wrote:
> Thans for your response.
>> with priority=5. Then a Modify command is issued by MGC with
>>     
> priority=7.
>   
>> Or, is it expected that a specific priority level set to a context
>>     
> will
>

---

From: "Miri Epstein" <[email-masked]>
Date: Tue, 26 Feb 2008 15:49:10 -0000

Hello Christian,

Thanks for pointing it out.

I was thinking about proposing that the emergency, priority, IEPS and
topology properties would be defined as properties of the
ContextAttribute descriptor instead of being "standalone" properties of
a context and being defined "outside" a descriptor. 

Exactly as the case of stream-dependent properties, e.g., where
package's properties can be defined in the LocalControl descriptor
besides the StreamMode property, ReserveGroup and ReserveValue
properties; package's properties that affect the context as a whole and
are considered as context properties should be defined in the
ContextAttribute descriptor _besides_ emergency, priority, IEPS and
topology properties. 
Viz, emergency, priority, IEPS and topology properties are context
attributes defined by H.248.1 as properties of the ContextAttribute
descriptor and additional context attributes can be defined via
packages. 

By this migration, the same behaviour is achieved for _all_ context
attributes regardless they are defined as part of H.248.1 or via
packages, since _all_ context attributes are defined as properties of
the ContextAttribute descriptor. 

Please note that the clause 6.1.1 in H.248.1v3 Amm.1 is not clearly
indicating that its scope is only these "standalone" properties (as
emergency, priority, IEPS and topology) not including a context
attribute defined as a property of the ContextAttribute descriptor. 

For a context attribute defined as a property of the ContextAttribute
descriptor, section 7.1.9 in H.248.1v3 declares that:

"A new setting of the ContextAttribute Descriptor completely replaces
the previous setting of that descriptor in the MG. Thus to retain
information from the previous setting the MGC must include that
information in the new setting. If the MGC wishes to delete some
information from the existing descriptor, it merely resends the
descriptor with the unwanted information stripped out." [7.1.9]

So, currently, the status is that emergency, priority, IEPS and topology
properties which are context attributes are manipulated differently from
the context properties defined in the ContextAttribute descriptor.

I'm aware that the ContextAttribute descriptor was added only in
H.248.1v3 while the emergency, priority and topology properties were
already defined as "standalone" in RFC 3525. 

In my opinion, with the addition of the ContextAttribute descriptor, the
correct handling is to define all context attributes as properties of
this descriptor.

As a result, I'm suggesting for H.248.1v4 to deprecate the "standalone"
context attributes: emergency, priority, IEPS and topology and re-define
them as properties of the ContextAttribute descriptor.

[Should this suggestion be made into a contribution...?]

Many thanks,
Miri

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 5:59 AM
To: Miri Epstein; megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Miri,

behaviour clear:
"In general, if a context attribute is completely omitted from a H.248 
action, the attribute of the corresponding context retains its prior
value."

Regards, Christian

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 26 Feb 2008 15:59:49 -0500

I would like to point out, for the record, that Topology is a descriptor
and not a parameter.  As such it is subject to all the rules regarding
descriptors.

Honestly, I don't see the problem.  If a descriptor is excluded, its
value is unchanged.  Similarly, the text in Amendment 1 states that this
rule applies to the context attributes.  The ContextAttributes
Descriptor is specifically not mentioned, since it would be handled as a
descriptor.

As for the syntax, it is what it is.  I proposed moving the context
attributes exactly the way you are proposing some years ago.  Backwards
compatibility of the syntax was a concern and the proposal was defeated.
In an ideal world, we would be able to go back and clean up many
notations in H.248 that are overly cumbersome.  However, the need for
backwards compatibility means that we have to work with what we have.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Miri Epstein
Sent: Tuesday, February 26, 2008 10:49 AM
To: Christian Groves; megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Christian,

Many thanks,
Miri

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, February 26, 2008 5:59 AM
To: Miri Epstein; megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Miri,

behaviour clear:

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Wed, 27 Feb 2008 18:04:54 +1100

Hello Miri,

I think Kevin has summarised the situation in his email. Each version of 
H.248.1 must be backwards compatible to the last. Clause 11.7 /H.248.1v3 
Amd.1 explains the rules for compatibility. Whilst we have deprecated 
elements of H.248.1 before (i.e. Modem descriptor) these were on item 
that nobody used. Emergency, priority and topology are used today. To 
deprecate these would not be possible. If we then added the ability to 
specify these as package specified context attributes then both forms 
would have to be supported.

Regards, Christian

Miri Epstein wrote:
>> I couldn't find any explicit reference to that issue in the standard.
>>     
> Am
>   
>> I missing it? If not, do you think this should go into the
>>     
> implementor's
>   
>> guide?
>>
>> the emergency, priority and topology properties are unique in not
>>     
> being
>   
>> part of a descriptor. This could have been solved if they were
>>     
> migrated
>   
>>> 1/ Assuming, for example, that a context was created by an Add
>>>       
> command
>   
>>> 2/ Assuming, for example, that a context was created by an Add
>>>       
> command
>   
>>> command omitting the emergency indicator is issued by the MGC. Does
>>>       
> it
>   
>>> 3/ Are these scenarios of modifying the context attributes
>>>       
> reasonable?
>   
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Miri Epstein" <[email-masked]>
Date: Wed, 27 Feb 2008 12:35:36 -0000

Hi Kevin,

Please see inline.

Thanks for your response,
Miri

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Tuesday, February 26, 2008 11:00 PM
To: Miri Epstein; Christian Groves; megaco ietf
Subject: RE: [Megaco] Emergency/Priority indicators

I would like to point out, for the record, that Topology is a descriptor
and not a parameter.  As such it is subject to all the rules regarding
descriptors.
<ME>: Sorry, my mistake. It shouldn't be include it with emergency,
priority and IEPS properties.

Honestly, I don't see the problem.  If a descriptor is excluded, its
value is unchanged.  Similarly, the text in Amendment 1 states that this
rule applies to the context attributes.  The ContextAttributes
Descriptor is specifically not mentioned, since it would be handled as a
descriptor.
<ME>: OK, but the comment was that it's not reasonable to have two types
of context attributes, with different behaviours.

As for the syntax, it is what it is.  I proposed moving the context
attributes exactly the way you are proposing some years ago.  Backwards
compatibility of the syntax was a concern and the proposal was defeated.
In an ideal world, we would be able to go back and clean up many
notations in H.248 that are overly cumbersome.  However, the need for
backwards compatibility means that we have to work with what we have.
<ME>: Yes, I agree. I'm happy to know that someone else saw the need of
such a migration. Thanks for the information.

Kevin

-----Original Message-----

Hello Christian,

Many thanks,
Miri

-----Original Message-----
From: Christian Groves [mailto:[email-masked]]
Sent: Tuesday, February 26, 2008 5:59 AM
To: Miri Epstein; megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Miri,

behaviour clear:

Regards, Christian

Am
implementor's

being
migrated

command
command
it
reasonable?

---

From: "Miri Epstein" <[email-masked]>
Date: Wed, 27 Feb 2008 12:36:18 -0000

Thanks.

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: Wednesday, February 27, 2008 9:05 AM
To: Miri Epstein
Cc: megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

Hello Miri,

Regards, Christian