Subject: RE: [Megaco] Sending wildcard response in Audit commands

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 7 Mar 2002 10:53:03 -0500

I'd like to get this adopted.  I'll reissue it if there is interest.

Brian

> -----Original Message-----
> From: Terry L Anderson [mailto:[email-masked]]
> Sent: Thursday, March 07, 2002 9:34 AM
> To: Naveen Krishnan
> Cc: Raphael Tryster; Tom-PT Taylor; Rosen, Brian; [email-masked]
> Subject: Re: [Megaco] Sending wildcard response in Audit commands
> 
> 
> Either the naming pattern for each MG must be provisioned into MGC or
> "discovered".  Brian Rosen has proposed a package that allows 
> MGC to discover
> the naming patterns from a MG 
> (draft-rosen-megaco-namepatterns-00.txt) but this
> has expired.  It supported both text and binary 
> terminationIDs.  Perhaps Brian
> can comment on his plans for reissuing the draft.
> 
> Naveen Krishnan wrote:
> 
> > Hi tla,
> >          Very nice explanation, but we do aware of this issue.
> >
> > Can U give us some solution(Widely used by vendors).
> >
> > For example If my MSC want to integrate with any vendors 
> MGW (if this is the
> > case) what are all the condition do i take care.
> >
> > Also can u suggest me some methods to Implement wildcard.
> >
> > -Naveen Krishnan
> >
> > ----- Original Message -----
> > From: tla <[email-masked]>
> > To: Naveen Krishnan <[email-masked]>
> > Cc: Raphael Tryster <[email-masked]>; Tom-PT Taylor
> > <[email-masked]>; Rosen, Brian <[email-masked]>;
> > <[email-masked]>
> > Sent: Thursday, March 07, 2002 11:30 AM
> > Subject: Re: [Megaco] Sending wildcard response in Audit commands
> >
> > > TerminationID does indeed have different ranges in text 
> and binary.
> > > Binary ids are much smaller, but with careful assignment 
> of meaning of
> > > each bit position it is still quite possible to use a hierarchical
> > > structure and use wildcards.  The fact that the notation 
> for binary and
> > > text differ is rarely a serious issue since it would be 
> rare for a MG to
> > > support both.  MGC may well need to understand at least two id
> > > structures if it supports both binary and text based MGs, but the
> > > structures of ids may not even be the same on multiple text MGs or
> > > multiple binary MGs, since there are no standard id 
> structures.  They
> > > would only be the same if all MGs are capable and 
> configured to use the
> > > same structure.  The structure of a terminationID was not 
> standardized
> > > because it was felt that there was no single right structure - it
> > > depends too much on the kinds of terminations supported 
> (SS7/TDM trunks
> > > might want vary different name structures than ATM, analog, etc.)
> > >
> > > There are groups that have defined profiles for specific kinds of
> > > terminations and define the structure of terminationIDs 
> but all I have
> > > seen also specify text only messages.
> > >
> > > Naveen Krishnan wrote:
> > >
> > > > Hi,      Once more question , how the Text and Binary 
> Termination ID
> > > > differ.If this is the case do we have to have two kind 
> of wildcard
> > > > implementation.       And in case of TDM Termination ID 
> , Do megaco as
> > > > any definition on the same like which byte is for 
> what(Which Byte
> > > > represent Timeslot, Trunk Group....) if we are not 
> having any standard
> > > > on this all the vendors will come out with there own 
> TDM termination
> > > > Structure, How are we going to handle it. -Naveen
> > > >
> > > >      ----- Original Message -----
> > > >      From: Raphael Tryster
> > > >      To: Tom-PT Taylor ; Rosen, Brian
> > > >      Cc: [email-masked]
> > > >      Sent: Thursday, March 07, 2002 12:05 AM
> > > >      Subject: RE: [Megaco] Sending wildcard response in Audit
> > > >      commands
> > > >       Hello Tom, Brian and list,
> > > >
> > > >      Now that you are thinking about wildcard responses, I would
> > > >      like to repeat something I posted a few weeks ago, but
> > > >      received no response.
> > > >
> > > >      Raphael Tryster
> > > >
> > > >      This is a part of a thread that stopped in September 2000,
> > > >      but it is not clear to me how it was resolved.  What Brian
> > > >      wrote agrees with the ABNF, and what Tom and John wrote is
> > > >      consistent with section 6.2.2, but they contradict each
> > > >      other.  The thread ended with this, seeming to imply
> > > >      agreement with Tom and John, but I do not see that the ABNF
> > > >      was amended to allow lists at the parameter value level.
> > > >
> > > >      Raphael Tryster
> > > >
> > > >      Message-ID:  <[email-masked]>
> > > >      Date:         Wed, 6 Sep 2000 11:10:07 +0200
> > > >      Reply-To: John Segers <[email-masked]>
> > > >      Sender: "Media Gateway Control (megaco)"
> > > >      <[email-masked]>
> > > >      From: John Segers <[email-masked]>
> > > >      Organization: Lucent Technologies
> > > >      Subject:      Re: Transaction Reply Context=ALL, wilcard
> > > >      response
> > > >      To: [email-masked]
> > > >      Content-Transfer-Encoding: 7bit
> > > >
> > > >      Tom,
> > > >
> > > >      This is my understanding as well.  Relevant text appears in
> > > >      section
> > > >      6.2.2:
> > > >              If individual responses are not required, 
> a wildcard
> > > >      response
> > > >              may be requested.  In such a case, a 
> single response
> > > >      is
> > > >              generated, which contains the UNION of all of the
> > > >      individual
> > > >              responses which otherwise would have been 
> generated,
> > > >      with
> > > >              duplicate values suppressed.  For instance, given a
> > > >      Termination
> > > >              Ta with properties p1=a, p2=b and Termination Tb
> > > >      with
> > > >              properties p2=c, p3=d, a UNION response would
> > > >      consist of a
> > > >              wildcarded TerminationId and the sequence of
> > > >      properties p1=a,
> > > >              p2=b,c and p3=d.
> > > >
> > > >      Cheers,
> > > >
> > > >      John
> > > >
> > > >      Tom-PT Taylor wrote:
> > > >      >
> > > >      > I always understood the intent of "W-" to mean that the
> > > >      response would show
> > > >      > unions at the most atomic level (i
> > > >      > was meant to show the range of values supported, not
> > > >      something intelligible
> > > >      > on a per-session basis.  I have to admit that it isn't
> > > >      necessarily clear
> > > >      > what a "parameter" is in SDP (i.e.) would all 
> "a=fmtp:" be
> > > >      collapsed into
> > > >      > one list?
> > > >      >
> > > >      > > -----Original Message-----
> > > >      > > From: Shalini Philip [ mailto:[email-masked]]
> > > >      > > Sent: Tuesday, September 05, 2000 4:21 AM
> > > >      > > To: [email-masked]
> > > >      > > Subject: Re: Transaction Reply Context=ALL, wilcard
> > > >      response
> > > >      > >
> > > >      > >
> > > >      > > Hello Brian, Christian & list.
> > > >      > >
> > > >      > >         The example given below shows multiple
> > > >      Statistics
> > > >      > > descriptors in
> > > >      > > the descriptor list for a command reply. I believe,
> > > >      > > the common understanding is that only the digit map
> > > >      descriptor and the
> > > >      > > error descriptors are the only two descriptors
> > > >      > > which can be repeated. If other descriptors can also be
> > > >      repeated, then
> > > >      > > we can have multiple Mux descriptors, if the
> > > >      > > MG supports multiple MUX types.
> > > >      > > Also since it is not feasible to take the union of SDP
> > > >      definitions in
> > > >      > > local and remote descriptors, I guess we can even have
> > > >      > > multiple local and remote descriptors , or do we put
> > > >      them as multiple
> > > >      > > SDP definitions in the same local/remote descriptor.
> > > >      > >
> > > >      > > Thanks & Regards,
> > > >      > >   Shalini Philip.
> > > >      > >
> > > >      > >
> > > >      > > "Rosen, Brian" wrote:
> > > >      > >
> > > >      > > >  I don't think you can do a subtract with CHOOSE.
> > > >      > > > You could use ALL, but not choose.
> > > >      > > >
> > > >      > > > If you ask for a wildcard response, I think you get
> > > >      one response per
> > > >      > > > value found, if they are different.  Since you get
> > > >      statistics on
> > > >      > > > results, any identical statistics reports would only
> > > >      be
> > > >      > > > repeated once.  So. assuming you used ALL, 
> I'd expect:
> > > >
> > > >      > > > C=1{Subtract=*{Statistics{...}, Statistics{...}....}.
> > > >      > > > C=2{...
> > > >      > > > ....
> > > >      > > >
> > > >
> > > >           -----Original Message-----
> > > >           From:   Tom-PT Taylor [SMTP:[email-masked]]
> > > >           Sent:   Wednesday, 06 March, 2002 2:43 PM
> > > >           To:     Technokrak; [email-masked]
> > > >           Subject:        RE: [Megaco] Sending wildcard response
> > > >           in Audit commands
> > > >
> > > >           The point of wildcarding is to get a summary of the
> > > >           responses.  If you need
> > > >           to know the properties of the individual terminations
> > > >           you have to audit them
> > > >           individually.
> > > >
> > > >           -----Original Message-----
> > > >           From: Technokrak [mailto:[email-masked]]
> > > >           Sent: Tuesday, March 05, 2002 12:03 AM
> > > >           To: [email-masked]
> > > >           Subject: [Megaco] Sending wildcard response in Audit
> > > >           commands
> > > >
> > > >           Hi All,
> > > >
> > > >           In the RFC, the use of wildcard response for Audit
> > > >           commands is
> > > >           highlighted.
> > > >
> > > >           For instance, given a Termination Ta with properties
> > > >           p1=a, p2=b and
> > > >              Termination Tb with properties p2=c, p3=d, a UNION
> > > >           response would
> > > >              consist of a wildcarded TerminationId and the
> > > >           sequence of properties
> > > >              p1=a, p2=b,c and p3=d.
> > > >
> > > >           But how can the MGC differentiate as to which of the
> > > >           set of properties
> > > >           belong to Termination Ta and which belong to
> > > >           Termination Tb??
> > > >
> > > >
> > > >           Regards
> > > >           Suman Choudhary
> > > >
> > > >           _______________________________________________
> > > >           Megaco mailing list
> > > >           [email-masked]
> > > >           https://www1.ietf.org/mailman/listinfo/megaco
> > > >
> > > --
> > > -------------------------------------------------------
> > > Terry L Anderson, DMTS                   [email-masked]
> > > Lucent Technologies /INS/ Voice over IP Access Networks
> > > Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> > > Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
> > > http://its.lucent.com/~tla  (Lucent internal)
> > > http://www.gti.net/tla
> > > -------------------------------------------------------
> > >
> > >
> 
> --
> -------------------------------------------------------
> Terry L Anderson, DMTS                   [email-masked]
> Lucent Technologies /INS/ Voice over IP Access Networks
> Rm 2B-121,   600 Mountain Ave, Murray Hill, NJ 07974
> Voice:908 582-7013  FAX:908 582-6226   Org:18E75000000
> http://its.lucent.com/~tla  (Lucent internal)
> http://www.gti.net/tla
> -------------------------------------------------------
> 
> 

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

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 07 Mar 2002 13:14:55 -0500

I am interested.  I could help advance it through the ITU but you may prefer
to push through IETF process.  Tom any problems getting it as a MEGACO work
item?

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 07 Mar 2002 13:14:55 -0500

--