Re: 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.

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 protected] [mailto:[email protected]] 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,

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 protected]]
Sent: Tuesday, February 26, 2008 5:59 AM
To: Miri Epstein; megaco ietf
Subject: Re: [Megaco] Emergency/Priority indicators

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:
> Hello Christian,
>
> Thans 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 protected]]
> Sent: Friday, February 22, 2008 1:10 AM
> To: Miri Epstein
> Cc: [email protected]; Shaikh, Viqar A. [RA]
> Subject: Re: [Megaco] Emergency/Priority indicators
>
> Hello Miri,
>
> Please see my replies below [CNG].
>
> Regards, Christian
>
> Miri Epstein wrote:
>   
>> 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?
>>   
>>     
> [CNG] Yes the priority would be 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?
>>   
>>     
> [CNG] If a Context property is omitted then it retains the previous 
> setting. So it would remain on.
>   
>> 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?
>>   
>>     
> [CNG] I would imagine that in most cases the priority would not be 
> changed once the call/connection is established.
>   
>>     
>> Thanks for your help,
>> Miri
>>
>>  
>> _______________________________________________
>> Megaco mailing list
>> [email protected]
>> http://www.ietf.org/mailman/listinfo/megaco
>>
>>
>>   
>>     
>
>
>   
_______________________________________________
Megaco mailing list
[email protected]
http://www.ietf.org/mailman/listinfo/megaco