Subject: [Megaco] Re: About ICASCo packages

From: lihu <[email-masked]>
Date: Mon, 05 Jan 2004 14:58:04 +0800

hi,kevin,
   In ICASCO package, the digitmap of "di" is described as below "if the di token does not include a DigitMap name or value,then the digit map defined within the EventsDescriptor is used.If a digit map is neither provided within the di portion of this parameter nor as an EventDM parameter,then digits are collected until end of pulsing digit is received."   But in fact,the end of pulsing digit is not always sent. So it will be compelling signaling timeout .  I think an extend sign should be defined to resolve the situation where no digitmap and end of pulse will be present. Perhaps, digit is notified  one by one may solve the problem.
  
   How do you think so ?

   Best regards

LiHu
Huawei co.,Ltd.
86-10-82882747

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

  ----- Original Message ----- 
  From: Kevin Boyle 
  To: lihu 
  Sent: Saturday, December 13, 2003 12:02 AM
  Subject: RE: About ICASCo packages

  Where does the 10 second figure come from?  Digitmap timers can be set and overridden to be whatever you want them to be.  I think you are placing artificial limits on the digitmap construct and on the package.

  I can assure you that using multiple digitmaps is possible -- we do it today in deployed products that support dialing plans from many different countries as well as international dialing.  Utilizing shorter timeouts and well-designed digitmaps will minimize the problems of digit collection delay.

  In the example you provide, the additional digits result in two extra messages each (a notify and a reply).  Each one of those messages is subject to latency and loss.  If either one of the messages for each digit is lost, that will result in retransmission, with the resultant delay for that digit, and also delay the notification of any further digits.  If the further digits are not held, then the digits could end up arriving at the MGC out of order, causing misrouting or call failure.  So the delays due to network latency and loss are encountered for each and every digit.  Fewer messages reduces the delay and loss impacts.

  Kevin

----------------------------------------------------------------------------
    From: lihu [mailto:[email-masked]] 
    Sent: Friday, December 12, 2003 12:59 AM
    To: Boyle, Kevin [NCRTP:3Z40:EXCH]
    Subject: Re: About ICASCo packages

    Because the if the total called number is collected by Timeout in Digitmap,it will induce more than 10 secends delay.And in some location ,the peer cas link will not send the end of pulse .So if the digitmap can't cover all possible dialing number,there is only to wait for timeout.

    Also there is an example ,why the mgc can't use one or more digitmap to get digit without using timeout in digitmap.
          MGC
           |
    R2----MG -----R2---international   called:080-010-114,  080-010-12345678
     if a call is international call ,and MGC don't know the called length.It can 
    send digitmap dm={080x.L}。If MGC send the digitmap={080},and the rest digits are collected in digit by digit,the time addressing called is more shorter than the former.

    Does digitmap have some other method to solve the addressing called time ?

    Best Regards

    LiHu
    Huawei co.,Ltd.
    86-10-82882747

      ----- Original Message ----- 
      From: Kevin Boyle 
      To: lihu 
      Sent: Friday, December 12, 2003 12:18 PM
      Subject: RE: About ICASCo packages

      Why do you have to use only one digitmap?  There is nothing that says that you cannot use a second digitmap after the first one completes.

      Secondly, your example is not representative of all dialing plans.  I personally know of some locations where digit series of more than 30 digits are collected and passed on for international trunk translations.  Further, the assertion that "there are only 2 messages more" is fine if you are talking about a single termination collecting digits.  But what if this is a large tandem office with tens of thousands of CAS circuits?  The "2 more messages" becomes far, far more messaging en masse.

      Certainly, if your MGC wishes to collect digits in this fashion, that's certainly up to you as the implementor.  However, it is highly inefficient and each additional message carries network latency and the potential for loss/retransmission.  So you are potentially worsening your delay problem, not improving it.

      I'm not sure what you mean on your third point.  mfd is not in hex.  There are discrete digit events, or there are digitmap symbols.  The only hex present in the package is the binary encodings.

      Kevin

------------------------------------------------------------------------
        From: lihu [mailto:[email-masked]] 
        Sent: Thursday, December 11, 2003 9:04 PM
        To: Boyle, Kevin [NCRTP:3Z40:EXCH]
        Subject: Re: About ICASCo packages

        Dear kevin,
         Because a perfect Digitmap is not easy to find, and also some center office(CO) can't decide whether the digit is collected completly.So the first part di are collected with icasco,the last part of di are collected with dd or mfd package.
        But if the icasco di'digitmap is improved with the ability of collecting digit by digit.So the icasco package is very flexible.The messages will only increase about 2 times of the collecting digit by digit.
        eg. di=123456 ,  MGC sends icaco di=dm{xxxx}, and the sends some other extend sign,
        which means the rest digit is notified digit by digit.
        There are only 2 messages more.
        Furthermore ,if mfd is used ,the notified content(hex code) should be convert to string.

        LiHu
        Huawei co.,Ltd.
        86-10-82882747

        ----- Original Message ----- 
          From: Kevin Boyle 
          To: lihu 
          Sent: Friday, December 12, 2003 8:08 AM
          Subject: RE: About ICASCo packages

          Digit by digit collection will result in a very large number of messages.  The balance will always be between delay and number of messages.  If you wish to do single digit collection, there is nothing prohibiting it -- use the dd or mfd package to look for single digits.  If, however, you are trying to strike a balance between number of messages and minimal delay, then your implementation will have to choose digitmaps that balance those two considerations appropriately for your particular implementation.

          Kevin

--------------------------------------------------------------------
            From: lihu [mailto:[email-masked]] 
            Sent: Thursday, December 11, 2003 5:56 AM
            To: Boyle, Kevin [NCRTP:3Z40:EXCH]
            Subject: About ICASCo packages

            Dear sir,
               In ICASCO package in <D-xxx_H.248.ICASC.doc>,it describes 3 kinds of di collecting .But the end of Digitmap and end of pulsing can induce some delay if 
            MGC  can't send a perfect Digitmap and the peer can't send end of pulsing.
            So a digit by digit way should be defined in ICASCO package' di.

            Does it have any way to solve it ?

            Bestregards

            LiHu
            Huawei co.,Ltd.
            86-10-82882747

            *****************************************************************
            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: lihu <[email-masked]>
Date: Mon, 05 Jan 2004 14:58:04 +0800

hi,kevin,
  
   How do you think so ?

   Best regards

LiHu
Huawei co.,Ltd.
86-10-82882747

  ----- Original Message ----- 
  From: Kevin Boyle 
  To: lihu 
  Sent: Saturday, December 13, 2003 12:02 AM
  Subject: RE: About ICASCo packages

  Kevin

    Best Regards

    LiHu
    Huawei co.,Ltd.
    86-10-82882747

      ----- Original Message ----- 
      From: Kevin Boyle 
      To: lihu 
      Sent: Friday, December 12, 2003 12:18 PM
      Subject: RE: About ICASCo packages

      Kevin

        Dear kevin,

        LiHu
        Huawei co.,Ltd.
        86-10-82882747

        ----- Original Message ----- 
          From: Kevin Boyle 
          To: lihu 

          Kevin

            Dear sir,

            Bestregards

            LiHu
            Huawei co.,Ltd.
            86-10-82882747