Re: Emergency/Priority indicators

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