Christian,
Actually in my initial message 1) and 2) did not correspond to two different options but were two parts of one and only potential solution. However, as I wrote in the same message, I'm not sure that it works in all cases. Therefore I would support your suggestion to go for a solution along the lines of adding a new event parameter.
Best Regards
Bruno
-----Message d'origine-----
De : Christian Groves [mailto:[email protected]]
Envoyé : mercredi 30 janvier 2008 03:57
À : CHATRAS Bruno RD-CORE-ISS; Kevin Boyle
Cc : [email protected]; [email protected]
Objet : Re: [Megaco] about completion events detection
Hello Bruno, Kevin
I agree there is an issue when the two digits maps complete at the same time as the embedding would be activated in both cases. The intention was to define the digitmaps in such a way that this did not occur. i.e.
something like your option 1, I think that it was missed that an unsuccessful match would still trigger an embedded descriptor.
Looking further into this I don't think that this option 1) aproach will result in the best behaviour. If we design the NonPriorityDM to match after the PriorityDM it will only fix the case where we have an emergency number e.g. 112. It still has the problem that if the number dialled isn't a priority number then a notification will be generated for the unsuccessful PriorityDM event which is not the desired overall behaviour.
The use of ResetEventsDescriptor (option 2) with the PriorityDM will solve the problem of sending the signal cg/st but may mean that the NonPriorityDM will never be matched because the MG will determine that there is an unsuccessful match with the PriorityDM first.
I don't know that there is any "quick" fix for this issue. The only solution that doesn't rely on a base syntax change is to introduce a new EventParameter to the digitmap completion events packages in H.248.1 and
H.248.16 which specifies that the event is detected only when a full successful match is determined. I've added Kevin who wrote most of the digit map sections to see if he has another idea.
Regards, Christian
[email protected] wrote:
> This would require a change to H.248.1, right?
> ----------------------------------------------------------------------
> -- *De :* Bill Xiaoshaoping [mailto:[email protected]] *Envoyé
> :* mardi 29 janvier 2008 15:03 *À :* CHATRAS Bruno RD-CORE-ISS;
> [email protected]; [email protected] *Objet :* Re: [Megaco]
> about completion events detection
>
> Hi Bruno,
>
> My apologies for not making my opinion clear.
> What I wanna say was puting only the PriorityDialPlan1 into the sight
> of the MG, that is, the MG can take autonomous actions to the mismatch
> result against PriorityDialPlan1.
> If we use more than one digitmap, we have to be very careful to make
> everything cooperated.
> Regards,
> Bill
>
> ----- Original Message -----
> *From:* [email protected]
> <mailto:[email protected]>
> *To:* [email protected] <mailto:[email protected]> ;
> [email protected] <mailto:[email protected]> ;
> [email protected] <mailto:[email protected]>
> *Sent:* Tuesday, January 29, 2008 5:38 PM
> *Subject:* RE: [Megaco] about completion events detection
>
> Well I'm not sure that Christian's answer solves the problem.
> Let's assume the following digit maps definitions:
> PriorityDialPlan1 = (112|117)
> NonPriorityDialPlan1 = (111 | [2-9]x.)
> If the user dials 112, two simultaneous actions will occur in the MG:
> 1) The first digit map will be matched
> 2) The MG will detect that the second digit map will never match
> According to H.248 7.1.14, both Digit Maps will complete at the
> same time.
> How does the MG know that only the first Completion Event shall be
> considered and therefore avoid that completion of the second digit
> maps trigger the embedded signal descriptor?
> Best Regards
> Bruno
>
> ------------------------------------------------------------------------
> *De :* Bill Xiaoshaoping [mailto:[email protected]]
> *Envoyé :* mardi 29 janvier 2008 09:04
> *À :* CHATRAS Bruno RD-CORE-ISS; [email protected]
> *Objet :* Re: [Megaco] about completion events detection
>
> Hi Bruno,
> Sorry I forgot to post the email from Christian Groves about this
> question.
> I think it is a good example from the perspective on
> specification, but this is more than an implementation issue,
> seems the MGC maybe take actions in time to xdd/xce event on
> PriorityDialPlan1 according to the termination method.
> There are various implementation to minimise congestion
> effectively in case of MGC overload, I personally would like to a
> solution that put the PriorityDialPlan1 only into the sight of the
> MG, and the MG take autonomous actions (including play congestion
> tone) to the mismatch case.
> Regards,
> Bill
> ----- Original Message -----
> *From:* Christian Groves <mailto:[email protected]>
> *To:* Bill Xiaoshaoping <mailto:[email protected]>
> *Cc:* 'Lin Yangbo' <mailto:[email protected]>
> *Sent:* Friday, November 09, 2007 7:48 AM
> *Subject:* Re: [Megaco] about completion events detection
>
> Hello Bill,
>
> There is a difference between H.248.1v2 and v3 with regards to the
> reporting of events these changes are discussed in the Notification
> Behaviour package in section H.248.1 E.15.
>
> With regards to the example the termination method isn't important.
> At off hook an embedded descriptor is triggered. This embedded
> descriptor sends dial tone and sets several events. Digits received by
> the MG are compared to the 2 digits maps. When digits are received
> that
> match one of the digit maps then that particular event is triggered.If
> the first digit map is matched then it indicates an emergency call and
> the MGC is notified. The MGC can then take the required action. If the
> second digit map is matched then it triggers an embedded signal
> (cg/ct)
> but does not notify the MGC. This is to minimise congestion.The 3rd
> event looks for an on-hook to clear the congestion tone or dial tone.
>
> Regards, Christian
>
> ----- Original Message -----
> *From:* [email protected]
> <mailto:[email protected]>
> *To:* [email protected] <mailto:[email protected]>
> ; [email protected] <mailto:[email protected]>
> *Sent:* Monday, January 28, 2008 5:58 PM
> *Subject:* RE: [Megaco] about completion events detection
>
> Hi!
> I'v not seen any comments on the issues raised in the below
> message. There seems to be indeed a problem with the current
> specification.
> One could think of avoiding this problem by using the
> following trick:
> 1) For each alternative in the PriorityDialPlan1, a dummy
> alternative is added to the NonPriorityDialPlan1 DM consisting
> of the same elements followed by "X."
> 2) Add ResetEventsDescriptor after ImmediateNotify.
> However, this does not sound like an elegant and efficient
> solution...I'm even not sure that it works in all cases...
> Any thoughts?
> Bruno
>
> ------------------------------------------------------------------------
> *De :* Bill Xiaoshaoping [mailto:[email protected]]
> *Envoyé :* jeudi 8 novembre 2007 10:10
> *À :* [email protected]
> *Objet :* [Megaco] about completion events detection
>
> Hi All,
>
> I have some doubt on the following message in
> E.15.5.2.2/H248.1 Version 3 ,
>
> Example message:
>
> Transaction=1234{
>
> Context = - {
>
> Modify = aln/* { ; select terminations as desired
>
> Events = 1234 {
>
> al/of {
>
> RegulatedNotify {
>
> Embed {
>
> Signals {cg/dt} ,
>
> ; If the off-hook is regulated apply dial tone.
>
> Events = 1235 {
>
> xdd/xce {
>
> DigitMap = PriorityDialPlan1,
>
> bc = 20,
>
> mp = enhanced,
>
> ImmediateNotify
>
> },
>
> ; If emergency generate notify to MGC
>
> xdd/xce {
>
> DigitMap = NonPriorityDialPlan1,
>
> bc = 20,
>
> mp = enhanced,
>
> NeverNotify,
>
> Embed{
>
> Signals {cg/ct}
>
> }
>
> },
>
> ; If non-priority send congestion tone and never notify
>
> al/on {
>
> NeverNotify,
>
> ResetEventsDescriptor
>
> }
>
> ; If on-hook is detected then reset the EventsDescriptor
>
> ; and never notify
>
> }
>
> }
>
> }
>
> }
>
> }
>
> }
>
> }
>
> }
>
> 1)I think the message can not achieve the expected effect
> because the xdd/xce is detected by the completion of the
> digitmap match procedure, not by the specific termination
> method, that is, "FM" or "PM". How can the MG consider the
> termination method is "PM" and not notify to the MGC, but
> switch to another match procedure(according to the comments in
> message)?
>
> 2)If one dials, the digit numbers will match the xdd/xce
> sequentially or simultaneously? If the former, we will
> encounter the above problem 1), and no order preference in
> descriptor in my impression. It is also a matter that whether
> the digits matched the first digitmap is still effective or
> not. If the latter, the user would hear a congestion tone
> every time make a call.
>
> Am I missing something(my apologies then)?
>
> Thanks
>
> Bill
>
> ***************************************************************************************
> This e-mail and its attachments contain confidential
> information from HUAWEI, which is intended only for the person
> or entity whose address is listed above. Any use of the
> information contained herein in any way (including, but not
> limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient(s)
> is prohibited. If you receive this e-mail in error, please
> notify the sender by phone or email immediately and delete it!
>
> **********************************************************************
> *****************
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.