Subject: RE: [Megaco] about completion events detection

From: <[email-masked]>
Date: Mon, 28 Jan 2008 10:58:24 +0100

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-masked]] 
Envoyé : jeudi 8 novembre 2007 10:10
À : [email-masked]
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 -_94a91e30-b457-4472-b4b1-975ee412eebb_--

--=======01142843=
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--=======01142843=--

---

From: <[email-masked]>
Date: Mon, 28 Jan 2008 10:58:24 +0100

Hi!

 

 
Any thoughts?
 
Bruno

Hi All,

Example message:

Transaction=1234{

   Context = - {

         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  

<mailto:[email-masked]> 
***************************************************************************************
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!
***************************************************************************************

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 10:38:07 +0100

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-masked]] 
Envoyé : mardi 29 janvier 2008 09:04
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]
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-masked]>  
To: Bill Xiaoshaoping <mailto:[email-masked]>  
Cc: 'Lin Yangbo' <mailto:[email-masked]>  
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-masked] 
	To: [email-masked] ; [email-masked] 
	Sent: Monday, January 28, 2008 5:58 PM
	Subject: RE: [Megaco] about completion events detection

	Hi!

	 

	 
	Any thoughts?
	 
	Bruno

	Hi All,

	Example message:

	Transaction=1234{

	   Context = - {

	         Events = 1234 { 

	            al/of { 

	               RegulatedNotify {

	                  Embed { 

	                     Signals {cg/dt} , 

	                     Events = 1235 {

	                         xdd/xce { 

	                            bc = 20, 

	                            mp = enhanced, 

	                            ImmediateNotify 

	                         }, 

	                         xdd/xce { 

	                            bc = 20, 

	                            mp = enhanced, 

	                            NeverNotify,

	                            Embed{

	                               Signals {cg/ct}

	                            }

	                          },    

	                          al/on { 

	                             NeverNotify, 

	                             ResetEventsDescriptor

	                          }

	; and never notify

	                      }

	                  }

	               }

	            }

	         }

	      }

	   }

	}

	 

	Thanks

	Bill  

	<mailto:[email-masked]>

---

From: <[email-masked]>
Date: Tue, 29 Jan 2008 16:41:58 +0100

This would require a change to H.248.1, right?

De : Bill Xiaoshaoping [mailto:[email-masked]] 
Envoyé : mardi 29 janvier 2008 15:03
À : CHATRAS Bruno RD-CORE-ISS; [email-masked]; [email-masked]
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-masked] 
	To: [email-masked] ; [email-masked] ; [email-masked] 
	Sent: Tuesday, January 29, 2008 5:38 PM
	Subject: RE: [Megaco] about completion events detection

	 

	 

	Best Regards
	Bruno

	Hi Bruno,

	 
	Regards,
	Bill

	----- Original Message ----- 
	From: Christian Groves <mailto:[email-masked]>  
	To: Bill Xiaoshaoping <mailto:[email-masked]>  
	Cc: 'Lin Yangbo' <mailto:[email-masked]>  
	Sent: Friday, November 09, 2007 7:48 AM
	Subject: Re: [Megaco] about completion events detection

	Hello Bill,

	
	Regards, Christian

		----- Original Message ----- 
		From: [email-masked] 
		To: [email-masked] ; [email-masked] 
		Sent: Monday, January 28, 2008 5:58 PM
		Subject: RE: [Megaco] about completion events detection

		Hi!

		 

		 
		Any thoughts?
		 
		Bruno

		Hi All,

		Example message:

		Transaction=1234{

		   Context = - {

		         Events = 1234 { 

		            al/of { 

		               RegulatedNotify {

		                  Embed { 

		                     Signals {cg/dt} , 

		                     Events = 1235 {

		                         xdd/xce { 

		                            bc = 20, 

		                            mp = enhanced, 

		                            ImmediateNotify 

		                         }, 

		                         xdd/xce { 

		                            bc = 20, 

		                            mp = enhanced, 

		                            NeverNotify,

		                            Embed{

		                               Signals {cg/ct}

		                            }

		                          },    

		                          al/on { 

		                             NeverNotify, 

		                             ResetEventsDescriptor

		                          }

		; and never notify

		                      }

		                  }

		               }

		            }

		         }

		      }

		   }

		}

		 

		Thanks

		Bill  

		<mailto:[email-masked]>

---

From: Christian Groves <[email-masked]>
Date: Wed, 30 Jan 2008 13:57:26 +1100

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-masked] wrote:
> ------------------------------------------------------------------------
> *De :* Bill Xiaoshaoping [mailto:[email-masked]]
> *Envoyé :* mardi 29 janvier 2008 15:03
> *À :* CHATRAS Bruno RD-CORE-ISS; [email-masked]; 
> [email-masked]
> *Objet :* Re: [Megaco] about completion events detection
>
> Hi Bruno,
>
> 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.
>     *From:* [email-masked]
>     <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]> ;
>     [email-masked] <mailto:[email-masked]>
>     *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:
>     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-masked]]
>     *Envoyé :* mardi 29 janvier 2008 09:04
>     *À :* CHATRAS Bruno RD-CORE-ISS; [email-masked]
>     *Objet :* Re: [Megaco] about completion events detection
>
>     Hi Bruno,
>     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
>     *From:* Christian Groves <mailto:[email-masked]>
>     *To:* Bill Xiaoshaoping <mailto:[email-masked]>
>     *Cc:* 'Lin Yangbo' <mailto:[email-masked]>
>     *Sent:* Friday, November 09, 2007 7:48 AM
>     *Subject:* Re: [Megaco] about completion events detection
>
>     Hello Bill,
>
>         *From:* [email-masked]
>         <mailto:[email-masked]>
>         *To:* [email-masked] <mailto:[email-masked]>
>         ; [email-masked] <mailto:[email-masked]>
>         *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.
>         1) For each alternative in the PriorityDialPlan1, a dummy
>         alternative is added to the NonPriorityDialPlan1 DM consisting
>         of the same elements followed by "X."
>         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-masked]]
>         *Envoyé :* jeudi 8 novembre 2007 10:10
>         *À :* [email-masked]
>         *Objet :* [Megaco] about completion events detection
>
>         Hi All,
>
>         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.
>
>         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!

---

From: <[email-masked]>
Date: Thu, 31 Jan 2008 16:18:23 +0100

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-masked]] 
Envoyé : mercredi 30 janvier 2008 03:57
À : CHATRAS Bruno RD-CORE-ISS; Kevin Boyle
Cc : [email-masked]; [email-masked]
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-masked] wrote:
> ----------------------------------------------------------------------
> -- *De :* Bill Xiaoshaoping [mailto:[email-masked]] *Envoyé 
> :* mardi 29 janvier 2008 15:03 *À :* CHATRAS Bruno RD-CORE-ISS; 
> [email-masked]; [email-masked] *Objet :* Re: [Megaco] 
> about completion events detection
>
> Hi Bruno,
>