RE: about completion events detection

<[email protected]>
Newsgroups gmane.ietf.megaco
Message-ID <2AF8FF7D89242541B12E7A47F6ECB4BE069C065F@ftrdmel3>
 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] 
	To: [email protected] ; [email protected] ; [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] 
		To: [email protected] ; [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  

		 

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

_______________________________________________
Megaco mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/megaco
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.