Re: Emergency/Priority indicators

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