From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jan 1 20:55:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29595 for ; Sat, 1 Jan 2000 20:55:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AC891390@standards.nortelnetworks.com>; Sat, 1 Jan 2000 20:42:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101639 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 1 Jan 2000 20:40:09 -0500 Received: from sepomex.gob.mx (200.33.29.1) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD494BD0@standards.nortelnetworks.com>; Sat, 1 Jan 2000 20:30:06 -0500 Received: from vgrra.hotbot.com by sepomex.gob.mx (8.8.8+Sun/SMI-SVR4) id SAA16489; Sat, 1 Jan 2000 18:53:47 -0600 (CST) Message-ID: <200001020053.SAA16489@sepomex.gob.mx> Date: Sat, 1 Jan 2000 18:53:47 -0600 Reply-To: ejdtaudhyj@HOTBOT.COM Sender: "Media Gateway Control (megaco)" From: ejdtaudhyj@HOTBOT.COM Subject: AUTOMATED MONEY-MAKING SYSTEM afwne X-To: bfvifqdzbd@aol.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM You Can Generate A Lifetime Residual Income On The Internet TELECOMMUTE your way to FINANCIAL FREEDOM while driving a COMPANY PAID CAR and living in a COMPANY PAID *HOUSE* For about the price of a decent vacuum cleaner, you can own your own personalized Internet Web Store and become a member of the Nutri-Net Online Marketing Team Not just a web page but your own personal 2000+ PAGE WEBSITE that you can use to generate a LIFETIME RESIDUAL INCOME! FINALLY an opportunity for the average person to build a FINANCIAL FUTURE using your computer and the internet. Your TURN-KEY Internet Store Operates 24-7-365 and is stocked with over 400 high quality products that SELL. Many are EXCLUSIVE! Your Internet Store does all of the selling for you and the company Ships Out The Products FOR YOU AUTOMATICALLY! Your AUTOMATED MONEY-MAKING SYSTEM includes the following: Automated Lead Generation Automated Followup - can handle 1000s of leads simultaneously! Deal only with HOT INTERESTED PROSPECTS NO selling or rejection ** All You Do Is USE THE *AUTOMATED* SYSTEM and CASH THE CHECKS! Now You Have A Way To MAKE MONEY AUTOMATICALLY 24 Hours a Day, 365 Days a Year! You owe it to yourself to check out this once in a lifetime home based business opportunity with a PROVEN 14-year-old, product-driven, publicly held NETWORK MARKETING COMPANY led by Professionals experienced in helping people like you MAKE MONEY on the Internet. ** These Pros Will SHOW YOU How To Work The SYSTEM For MAXIMUM PROFITS! JUMP ON IT! Send Your: Name: Phone Number and Email address mailto:leaders@n2mail.com?subject=more --------------------------- Remove requests Honored mailto:outpl@fiberia.com?subject=out From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Jan 2 12:31:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09426 for ; Sun, 2 Jan 2000 12:31:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F5EC790@standards.nortelnetworks.com>; 2 Jan 2000 12:19:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101892 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 2 Jan 2000 12:17:56 -0500 Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.661F2BA0@standards.nortelnetworks.com>; 2 Jan 2000 12:17:55 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA26042; Sun, 2 Jan 2000 09:43:25 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA19577; Sun, 2 Jan 2000 09:28:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF068574@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14447.35491.457621.505737@thomasm-u1.cisco.com> Date: Sun, 2 Jan 2000 09:28:03 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF068574@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit I'm coming in late here, so forgive me if I'm coming from left field. I think that people are missing an important point here, if I understand Brian correctly. The MGC needs to be able to specify policy both for groupings (eg, G.729 + DTMF relay) and choices (G.729 or G.711), The MGC should *not*, however, tell the MG to prepare itself to receive all of those codecs *simultaneously* as the solution to the problem. The reason here is pragmatic: DSP's have limited amounts of memory, and many of them swap codec code in and out of their fast memory. Therefore saying that the DSP must be able to simultaneously handle G.729, G.728, G.726 and G.711 when that is really a set of "choose one" alternatives is going to cause a whole lot of implementations to give resource errors instead of the desired semantics. Mike Rosen, Brian writes: > Negotiation is always between two MGCs. Negotiation always starts with > capability. So there is a message > from MGC to MG to ask for capability. It can express policy, but it doesn't > have to. Then the two MGCs negotiate. > Then both MGCs tell their respective MGs what the result is. One end does > that right away (the end that > decides). The other end has to wait for the message from the distant MGC > before it can tell its MG. In fast start, > the terminating MG is the decision maker, so it gets capability from its MG, > decides based on what it's MG can do, and what the originating MGC said the > originating MG can do, and tells it's MG what to do. > > We are bending SDP pretty hard. Having yet another bend so that you can > differentiate between "choose one > of these" and "here is my policy, tell me your capability" is getting > pretty bad. This is why I liked using > remote and local rather than sendonly or Nancy's vertical bar -- less > modification to SDP syntax. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, December 22, 1999 7:51 PM > To: Rosen, Brian > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > > > I've had to think about this a bit, because I have a couple of problems with > it. The main problem is that there doesn't seem to be any point of > convergence -- the terminating MG sends back its version of Local and Remote > to its MGC "and then negotiation occurs" (your words). Negotiation between > what entities? Does there now have to be another round of messaging to tell > the MGs what the MGCs have decided, at the terminating end as well as at the > originating end? > > Actually, I think I can leave this up to the implementation. We can simply > have a rule that the MG echoes back that subset of whatever the MGC proposes > that the MG can support. If I want to save a message by making the final > decision in the terminating MGC BEFORE sending a message down to the MG > that's my business as an MGC implementor. > > On your concern about getting capability after policy is set: you can always > do an AuditCapability on the termination to start with if you want to be > perfect. The reason the MGC imposes policy has to do with the signalling it > has received, or resources it is trying to husband. Knowing more precisely > the instantaneous capability of the MG isn't going to change those factors. > > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Wednesday, December 22, 1999 3:10 PM > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > In my view each end independently has policy, each end independently > has capability. > Each end independently applies policy to capability and ends up with an > ordered list > of candidates. The negotiation is then to select the first candidate that > both ends > can support. This results in a single answer, which is communicated to both > sides. > > Suppose the originating MG can do G.711, G.723 and G.729. The policy of > the the MGC > is G.729, then G.726, then G.711, it won't allow G.723. Suppose the > terminating end MG has the same capability but the policy at its MGC is > G.711 then G.726, then G.729. > > > So the originating MGC sends 729, 726, 711, the originating MG responds 729, > 711. > The terminating MGC sends 711, 726, 729, the terminating MG responds 711, > 726, 729. > The negotiation occurs. In this case the negotiation would result in 711, > and both > ends would set local and remote to 711. Note that different MGC-MGC > protocols would have different rules on how negotiation proceeded, but all > of them would start with an ordered list of possibles, eliminate the ones > that only one side can support, and select among the remaining ones. > > > I'm a little bothered by the send policy, get capability. It seems > backwards to me; if I were > designing the system, I might be inclined to get a complete capability, > filter it by policy and > then negotiate the result. However, the MG has to reserve resources for the > worst case of the alternatives it allows. Therefore, it wants to know the > policy so that it does not reserve resources for options the MGC would not > allow. On the other (other) hand, making the > > MG enforce MGC policy also seems wrong - the MGC should enforce it's > own policy. > So, I'd accept the idea that the MG simply states network, nothing else, the > MG responds with capability. The MGC filters that with policy, negotiates > it, and then sends the single > > result to the MG. The way we have it is okay, and as I observe, may > leave the MG with > more available resource. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com > ] > Sent: Wednesday, December 22, 1999 11:48 AM > To: Rosen, Brian > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > > > Could we take this one step further toward concreteness? A couple > of points have been bothering me: how does the MG at the originating end > know which alternatives to offer, and at the terminating end what does the > MG do with Remote? Furthermore, how does the MGC tell the MG: "This is what > you're going to use; we're not negotiating any more."? > > I've also realized that unless both send and receive capabilities > can be expressed in the same descriptor, there is no way for the originating > MG at least to express joint capabilities for asymmetric connections. We > may be able to live without this. Certainly the H.323 crowd would prefer to > do so, since H.245 and H.323 fastStart both separate capabilities by > direction of flow. > > These are my answers to my own questions, starting from the premise > that Local describes received flows, Remote describes transmitted flows. > > (1) At the originating end, the MGC may supply a set of alternative > session descriptions (mutually exclusive alternatives) and within each a > list of one or more payload types. Here's the key point: the MG in its > response is constrained by the list of payload types -- it can't offer any > not listed in the first place by the MGC. However, it can offer > alternatives for detailed parameters associated with those payload types. > This is especially necessary with video, where the list of possible > alternatives can go on forever. We'll have to think a bit about the syntax > for offering these alternatives -- yet more session descriptions or ranges > or whatever. > > (2) At the terminating end, the MGC takes the signalled send and > receive capabilities from the far end. (If the signalling is via SDP and > capabilities are not broken out by direction, symmetric flow capabilities > are assumed.) The terminating MGC may filter out non-starters from its > policy viewpoint, then it will build Local and Remote from what remains. > > Now the question is what rule the MG follows to evaluate what is > presented. First off, I assume we want the MG to choose a single > alternative at this point. How is that indicated by the MGC? I would > favour an explicit parameter in LocalControl rather than a rule like "If > Remote is present, choose a single alternative rather than presenting > alternatives.". > > > > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Wednesday, December 22, 1999 10:46 AM > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > Cc: Megaco (E-mail) > Subject: RE: Proposed Text For Media Specification > > In defense of the position I would point out that when the > MG supplies it's version of local it is BEFORE negotiation > takes place. This has to be true because it has to reserve > resources and report what it could support. The MGC must take > that set of alternatives and negotiate with its opposite MGC. > The result of that negotiation has to be one, agreed upon session > description that both MGs can support. > > Given that, I think the MG must offer a set of alternatives. > > > Brian > > -----Original Message----- > > From: Tom-PT Taylor [ < mailto:taylor@nortelnetworks.com > >] > > Sent: Wednesday, December 22, 1999 10:40 AM > > To: Chip Sharp; Brian Rosen; megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > > > I'm willing to follow this thought along a bit further. I think the > > concrete difference between the viewpoint I've documented and the > > "policy-capability" viewpoint is this: if the MGC sends down > > a number of > > alternative session descriptions, in my case the MG picks > > one, while in > > Brian's case the MG replies with all the session descriptions it can > > currently support. I am willing to accept the latter > > proposition if we can > > all agree on it. From there, I will go forward with Chip's > > distinction > > between the roles of Local and Remote, and I think we'll have a good > > sensible result. > > > > > > > RE: Proposed Text For Media Specification > > > >
class=090593815-23121999>Negotiation is always between two MGCs.  > Negotiation always starts with capability.  So there is a > message
>
from > MGC to MG to ask for capability.  It can express policy, but it doesn't > have to.  Then the two MGCs negotiate.
>
Then > both MGCs tell their respective MGs what the result is.  One end does that > right away (the end that
>
class=090593815-23121999>decides).  The other end has to wait for the > message from the distant MGC before it can tell its MG.  In fast > start,
>
the > terminating MG is the decision maker, so it gets capability from its MG, decides > based on what it's MG can do, and what the originating MGC said the originating > MG can do, and tells it's MG what to do. 
>
class=090593815-23121999> 
>
We are > bending SDP pretty hard.  Having yet another bend so that you can > differentiate between "choose one
>
of > these" and "here is my policy, tell me your capability"  is getting pretty > bad.  This is why I liked using
>
remote > and local rather than sendonly or Nancy's vertical bar -- less modification to > SDP syntax.
>
class=090593815-23121999> 
>
class=090593815-23121999>Brian
>
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px"> >
size=2>-----Original Message-----
From: Tom-PT Taylor > [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, December 22, > 1999 7:51 PM
To: Rosen, Brian
Cc: > megaco@standards.nortelnetworks.com
Subject: RE: Proposed Text For > Media Specification

>

I've had to think about this a bit, > because I have a couple of problems with it.  The main problem is that > there doesn't seem to be any point of convergence -- the terminating MG sends > back its version of Local and Remote to its MGC "and then negotiation occurs" > (your words).  Negotiation between what entities?  Does there now > have to be another round of messaging to tell the MGs what the MGCs have > decided, at the terminating end as well as at the originating end?

>

Actually, I think I can leave this up > to the implementation.  We can simply have a rule that the MG echoes back > that subset of whatever the MGC proposes that the MG can support.  If I > want to save a message by making the final decision in the terminating MGC > BEFORE sending a message down to the MG that's my business as an MGC > implementor.

>

On your concern about getting > capability after policy is set: you can always do an AuditCapability on the > termination to start with if you want to be perfect.  The reason the MGC > imposes policy has to do with the signalling it has received, or resources it > is trying to husband.  Knowing more precisely the instantaneous > capability of the MG isn't going to change those factors.

>
    >

    -----Original Message-----
    face=Arial size=1>From:   size=1>Rosen, Brian [SMTP:brosen@fore.com]
    size=1>Sent:   Wednesday, > December 22, 1999 3:10 PM
    size=1>To:     size=1>Taylor, Tom-PT [CAR:B904-I:EXCH]
    size=1>Cc:     size=1>megaco@standards.nortelnetworks.com
    size=1>Subject:        face=Arial size=1>RE: Proposed Text For Media Specification

    >

    In my view each end independently > has policy, each end independently has capability.
    color=#0000ff face=Arial size=2>Each end independently applies policy to > capability and ends up with an ordered list
    face=Arial size=2>of candidates.  The negotiation is then to select the > first candidate that both ends
    size=2>can support.  This results in a single answer, which is > communicated to both sides.
      >
    Suppose the originating MG can do > G.711, G.723 and G.729.   The policy of the the MGC >
    is G.729, then G.726, then G.711, > it won't allow G.723.  Suppose the terminating end MG has the same > capability but the policy at its MGC is G.711 then G.726, then > G.729.

    >

     
    size=2>So the originating MGC sends 729, 726, 711, the originating MG > responds 729, 711.
    The > terminating MGC sends 711, 726, 729, the terminating MG responds 711, 726, > 729.
    The negotiation > occurs.  In this case the negotiation would result in 711, and > both
    ends would set local > and remote to 711.  Note that different MGC-MGC protocols would have > different rules on how negotiation proceeded, but all of them would start > with an ordered list of possibles, eliminate the ones that only one side can > support, and select among the remaining ones.

    >

     
    size=2>I'm a little bothered by the send policy, get capability.  It > seems backwards to me;  if I were
    face=Arial size=2>designing the system, I might be inclined to get a > complete capability, filter it by policy and
    face=Arial size=2>then negotiate the result.  However, the MG has to > reserve resources for the worst case of the alternatives it allows.  > Therefore, it wants to know the policy so that it does not reserve > resources for options the MGC would not allow.  On the other (other) > hand, making the

    >

    MG enforce MGC policy also seems > wrong - the MGC should enforce it's own policy.
    color=#0000ff face=Arial size=2>So, I'd accept the idea that the MG simply > states network, nothing else, the MG responds with capability.  The MGC > filters that with policy, negotiates it, and then sends the > single

    >

    result to the MG.  The way we > have it is okay, and as I observe, may leave the MG with
    color=#0000ff face=Arial size=2>more available resource.
    face=Arial> 
    size=2>Brian

    >
      >

      -----Original Message-----
       face=Tahoma size=2>From: Tom-PT Taylor > [ href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.com face=Tahoma size=2>]
       size=2>Sent: Wednesday, December 22, > 1999 11:48 AM
      To: face=Tahoma size=2> Rosen, Brian
       size=2>Cc: > megaco@standards.nortelnetworks.com
       size=2>Subject: RE: Proposed Text For > Media Specification

      >

      Could we take this one step > further toward concreteness?  A couple of points have been bothering > me: how does the MG at the originating end know which alternatives to > offer, and at the terminating end what does the MG do with Remote?  > Furthermore, how does the MGC tell the MG: "This is what you're going to > use; we're not negotiating any more."?

      >

      I've also realized that unless > both send and receive capabilities can be expressed in the same > descriptor, there is no way for the originating MG at least to express > joint capabilities for asymmetric connections.  We may be able to > live without this.  Certainly the H.323 crowd would prefer to do so, > since H.245 and H.323 fastStart both separate capabilities by direction of > flow.

      >

      These are my answers to my own > questions, starting from the premise that Local describes received flows, > Remote describes transmitted flows.

      >

      (1) At the originating end, the > MGC may supply a set of alternative session descriptions (mutually > exclusive alternatives) and within each a list of one or more payload > types.  Here's the key point: the MG in its response is constrained > by the list of payload types -- it can't offer any not listed in the first > place by the MGC.  However, it can offer alternatives for detailed > parameters associated with those payload types.  This is especially > necessary with video, where the list of possible alternatives can go on > forever.  We'll have to think a bit about the syntax for offering > these alternatives -- yet more session descriptions or ranges or > whatever.

      >

      (2) At the terminating end, the > MGC takes the signalled send and receive capabilities from the far > end.  (If the signalling is via SDP and capabilities are not broken > out by direction, symmetric flow capabilities are assumed.)  The > terminating MGC may filter out non-starters from its policy viewpoint, > then it will build Local and Remote from what remains.

      >

      Now the question is what rule the > MG follows to evaluate what is presented.  First off, I assume we > want the MG to choose a single alternative at this point.  How is > that indicated by the MGC?  I would favour an explicit parameter in > LocalControl rather than a rule like "If Remote is present, choose a > single alternative rather than presenting > alternatives.".



      >

              size=1>-----Original Message----- face=Arial>
       size=1>From:   face=Arial size=1>Rosen, Brian [SMTP:brosen@fore.com] face=Arial>
       size=1>Sent:   face=Arial size=1>Wednesday, December 22, 1999 10:46 AM face=Arial>
       size=1>To:     > Taylor, Tom-PT > [CAR:B904-I:EXCH]
       size=1>Cc:     > Megaco (E-mail) face=Arial>
       size=1>Subject:        face=Arial> RE: Proposed Text For Media > Specification

      >

              In > defense of the position I would point out that when the face=Arial>
      MG supplies it's version of > local it is BEFORE negotiation
       face=Arial size=2>takes place.  This has to be true because it has to > reserve
       size=2>resources and report what it could support.  The MGC must > take
      that set of > alternatives and negotiate with its opposite MGC. face=Arial>
      The result of that > negotiation has to be one, agreed upon session face=Arial>
      description that both MGs > can support.

      >

              size=2>Given that, I think the MG must offer a set of > alternatives.

      >

              size=2>Brian
       size=2>> -----Original Message----- face=Arial>
      > From: Tom-PT Taylor > [ < href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelnetworks.com> face=Arial size=2>]
       size=2>> Sent: Wednesday, December 22, 1999 10:40 AM face=Arial>
      > To: Chip Sharp; Brian > Rosen; megaco@standards.nortelnetworks.com face=Arial>
      > Subject: RE: Proposed > Text For Media Specification
       face=Arial size=2>>
      size=2>>
      > I'm willing to follow > this thought along a bit further.  I think the face=Arial>
      > concrete difference > between the viewpoint I've documented and the face=Arial>
      > "policy-capability" > viewpoint is this: if the MGC sends down
      size=2>> a number of
       size=2>> alternative session descriptions, in my case the MG > picks
      > one, while in face=Arial>
      > Brian's case the MG > replies with all the session descriptions it can face=Arial>
      > currently > support.  I am willing to accept the latter
      face=Arial size=2>> proposition if we can face=Arial>
      > all agree on it.  > From there, I will go forward with Chip's
      size=2>> distinction
       size=2>> between the roles of Local and Remote, and I think we'll have > a good
      > > sensible result.
       size=2>>

From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Jan 2 14:49:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09936 for ; Sun, 2 Jan 2000 14:49:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14F57E00@standards.nortelnetworks.com>; 2 Jan 2000 14:38:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101935 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 2 Jan 2000 14:37:15 -0500 Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD1B8C90@standards.nortelnetworks.com>; 2 Jan 2000 14:37:15 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id LAA00835; Sun, 2 Jan 2000 11:41:33 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA19606; Sun, 2 Jan 2000 11:47:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF06855D@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14447.43852.913024.153961@thomasm-u1.cisco.com> Date: Sun, 2 Jan 2000 11:47:24 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF06855D@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit As you mention, SDP does not have the ability to specify choices as it is currently instantiated. Until that changes, I suggest we live with the redundancy. Have I mentioned recently that the use of multiple SDP's to specify alternatives is going to lead to combinatorial explosion? Codecs are not the only thing that we may want to negotiate, after all. In packetcable, cipher suites are negotiated as well. Mike Rosen, Brian writes: > Yes, several of us have been discussing this. > > It stems from the prior paradigm where: > 1. The MGC sent policy to the MG in localcontrol > 2. The MG sent capability to the MGC in local > 3. The MGC sent negotiated decision to the MG in local > > To do this, it is necessary to duplicate all the parameters you > might have policy and/or capability in both local and localcontrol. > This is silly. So Tom proposed that we change the sequence > to: > 1. The MGC sends policy to the MG in local > 2. The MG sent capability to the MGC in local > 3. The MGC sent negotiated decision to the MG in local > Restricting all the policy/capability parameters to local. > > It means a change to the SDP that the MG/MGC exchange to allow > specification of choice, and also to deal with asymmetric parameters > that H.245 can express. > > Brian > > -----Original Message----- > > From: Chip Sharp [mailto:chsharp@cisco.com] > > Sent: Wednesday, December 22, 1999 1:12 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Proposed Text For Media Specification > > > > > > This would totally change the operation of H.248 from the > > current operation > > in which the MGC never sends a Local Descriptor. Sounds like > > you want to > > use Local Descriptor to send commands to the MG. > > > > Chip > > > > At 09:26 PM 12/21/99 -0500, Tom-PT Taylor wrote: > > >I am proposing the following changes to section 7.1.8 "Local > > and Remote > > >Descriptors", in line with the apparent agreement of the WG > > that aside from > > >purely local matters the MGC should assert its control over > > media via the > > >Local and Remote descriptors. > > > > > >Delete the second paragraph entirely. > > > > > >Replace it with the following text: > > > > > > > > > > > >The Local descriptor reserves resources on the local MG for > > media reception. > > >The following rules apply to the use of the Local Descriptor: > > > > > >(1) Each session description contained within the Local > > Descriptor specifies > > >an alternative which the MG may use for encoding and > > decoding the given > > >stream. The MG must choose a single alternative from > > amongst those offered. > > > > > >(2) Any one session description MUST contain either one or > > two media-level > > >descriptions. If there are two media-level descriptions, > > one applies to > > >received media (media decoding), the other to transmitted > > media (media > > >encoding). The direction of media flow for a given media > > description is > > >indicated by the presence of the "a=recvonly" or > > "a=sendonly" attribute > > >respectively, or the Annex C equivalent. If there is just > > one media-level > > >description, it MAY contain a directionality attribute; if > > it does not, the > > >media flow is assumed to be symmetric. A media-level > > description pertaining > > >to an > > > > > >(3) Within any session description, the MGC may use the UNSPECIFIED > > >placeholder [proposed to be "-" for text encoding] to > > indicate a parameter > > >value which can only be assigned by the remote device. The > > MG must search > > >for the corresponding value within the Remote Descriptor and > > substitute its > > >value. It is an error for the MGC to enable a flow in > > either direction > > >(through its setting of the Mode parameter in LocalControl) > > before all > > >UNSPECIFIED values have been resolved. Upon detection of > > such an error the > > >MG must reject the transaction and return the error > > indication 441, "Missing > > >RemoteDescriptor". > > > > > >(4) Within the session description which the MG chooses to > > support, if > > >multiple media encodings are specified, the MG must reserve > > the resources to > > >handle all of them. To be more specific, it must reserve > > resources in > > >accordance with the following assumptions: > > > - for transmitted media content the encodings are listed > > in decreasing > > >order of preference. If a given encoding is applicable only > > to a subset of > > >media content (e.g. the new tones payload type) then less-preferred > > >encodings will also be used as required to process the outgoing flow. > > > - for received media content, the incoming flow may switch > > at any time > > >between any of the specified encodings. > > > > > >(5) The MGC may use the CHOOSE wildcard in place of most > > parameter values, > > >with the specific exception of network type and medium type. > > (Network type > > >MUST always be the same as that indicated in the Network > > Type property in > > >TerminationState. Depending on the implementation, the MG > > will require that > > >the medium type for a given stream be the same for all > > terminations in the > > >same context, or may allow certain implicit transformations such as > > >text-to-voice.) The MG is free to assign any value to the > > wildcarded item > > >which is consistent with the remainder of the media > > description. It must > > >return the Local Descriptor with the assigned values in its response. > > > > > >(6) If the MG is unable to reserve sufficient resources to > > support any of > > >the offered alternatives it must reject the transaction, > > returning error > > >510, "Insufficient resources". > > > > > >(7) If the MG successfully reserves resources for one of the offered > > >alternatives, and the Local Descriptor originally supplied > > by the MGC was > > >under-specified either through use of the CHOOSE wildcard or through > > >omission of attributes for which the MG is able to supply > > default values, > > >the MG must return a completed Local Descriptor in its > > response, showing the > > >values which it has supplied. This may require the use of > > one or more > > >"a=fmtp..." attribute lines or the Annex C equivalent to > > show additional > > >format parameters individually for each media encoding > > within the session > > >description. > > > > > >The Remote Descriptor describes resources reserved in the > > remote device. > > >The MGC may initially omit the Remote Descriptor, but must > > ensure that any > > >UNSPECIFIED values are resolved before the affected flows > > are activated, as > > >mentioned in rule (3) above. It is an error for the MGC to specify > > >inconsistent Local and Remote Descriptors. If the MG > > detects such an error > > >it must reject the transaction, returning error ??? [need one]. > > > > > >The MG uses the Remote Descriptor for two purposes: > > > - to resolve any UNSPECIFIED values present in the Local Descriptor > > > - to add details of specification (such as additional > > attribute values for > > >a given encoding) which are not present in the Local > > Descriptor provided by > > >the MGC. > > >It is possible that the additional detail provided by the > > Remote Descriptor > > >creates a configuration which cannot be supported by the MG, > > even though it > > >can support the Local Descriptor. In this case, as in rule > > (6) above, the > > >MG rejects the transaction with error 510, "Insufficient resources". > > > > > > > > > > > >Tom Taylor > > >Advisor -- IPConnect Standards > > >E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > >Phone and FAX: +1 613 736 0961 > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 10:33:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02826 for ; Mon, 3 Jan 2000 10:33:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.603BC220@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:22:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102277 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 10:20:14 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA260450@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:10:14 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA18478; Mon, 3 Jan 2000 10:20:26 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA23247; Mon, 3 Jan 2000 10:20:27 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 10:18:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Message-ID: <4FBEA8857476D311A03300204840E1CF0685AA@whq-msgusr-02.fore.com> Date: Mon, 3 Jan 2000 10:20:26 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Property types and parameter types X-To: Gunnar Hellstrom To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02826 I had not been aware anyone wanted "sub lists". If we REALLY need it, we should put it in, and as you observe, it should be the same in 12.1.2 and 12.2. Brian > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@OMNITOR.SE] > Sent: Wednesday, December 29, 1999 5:47 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Property types and parameter types > > > In the work with packages, I have hit a little inconsistency > that I would > like to have clarified: > > There is a difference in H.248 version 12 between the types valid for > properties and the types valid for parameters. > Among property types, "Lists or sub-list" and "Boolean" are > missing. The > definition of Enumeration is also different: 12.1.2 Indicates "List of > possible values" while 12.2 indicates "One of a list of > possible unique > values". > > I suggest that the types defined for parameters in 12.2 is > copied also to > 12.1.2. > > Specifically I have a need to distinguish between > > 1) One value from an Enumeration. I intend to call that type > "Enumeration". > > 2) A selection of one or more values from an Enumeration. I > intend to call > that type "sub-list" > > Is this according to general understanding? > > Examples: > > Property Call types > Type: Sub-list > Possible Values: > fax > text > data > Description: > A set of enabled call types monitored for in the call type > discrimination > package. > (may be set to "fax, text" if we are only interested in > supporting these > types) > > > Property Call type > Type: Enumeration > Possible values: > fax > text > data > Description: > One specific call type that is selected or detected. > ( may be set to "text" during a text conversation call ) > > Is it allowed to do as in the example, to enumerate the > possible values for > the members in the sub-list under "Possible values" ? > > > Regards > Gunnar > ______________________________________ > Gunnar Hellström > Omnitor AB > Alsnögatan 7, 4tr > S-116 41 Stockholm > Sweden > > Mob +46 708 204 288 > Tel +46 8 556 002 03 > Fax +46 8 556 002 06 > Video +46 8 556 002 05 > Txt (All kinds) +46 8 556 002 05 > E-mail gunnar.hellstrom@omnitor.se > WWW: http://www.omnitor.se > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 10:33:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02828 for ; Mon, 3 Jan 2000 10:33:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.653011A0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:22:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102322 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 10:22:07 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62B13180@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:22:06 -0500 Received: from oleane (dyn-1-1-234.Vin.dialup.oleane.fr [195.25.4.234]) by smtp2.cluster.oleane.net with SMTP id QAA76554; Mon, 3 Jan 2000 16:32:14 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01BF5607.C0ED4C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <007901bf55ff$61e85220$0401a8c0@oleane.com> Date: Mon, 3 Jan 2000 16:29:49 +0100 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: VoDSL 2000 Conference To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0076_01BF5607.C0ED4C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 The VoDSL 2000 Conference will stand in Paris next 28-31 March. Key = speakers, case studies: take a look at: = http://www.upperside.fr/bavodsl.htm =20 Regards ------=_NextPart_000_0076_01BF5607.C0ED4C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
The VoDSL 2000 Conference will stand = in Paris=20 next 28-31 March. Key speakers, case studies: take a look at:  http://www.upperside.fr/bavo= dsl.htm
 
Regards
 
 
------=_NextPart_000_0076_01BF5607.C0ED4C00-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 10:37:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02883 for ; Mon, 3 Jan 2000 10:37:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE3415E0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:24:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102278 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 10:23:29 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E466910@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:13:29 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA18841; Mon, 3 Jan 2000 10:23:41 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA24246; Mon, 3 Jan 2000 10:23:42 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 10:21:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685AB@whq-msgusr-02.fore.com> Date: Mon, 3 Jan 2000 10:23:39 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM The "reserve" is worst case resource, not simultaneous. So if the DSP is already running G.726, and G.723 takes fewer DSP cycles than G.729, if the MG offers G.726, G.723, G.729, it would have to reserve enough DSP cycles to do G.729. We will have to be careful about wording to make this clear. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Sunday, January 02, 2000 12:28 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > > > I'm coming in late here, so forgive me if I'm coming > from left field. > > I think that people are missing an important point > here, if I understand Brian correctly. The MGC > needs to be able to specify policy both for > groupings (eg, G.729 + DTMF relay) and choices > (G.729 or G.711), The MGC should *not*, however, > tell the MG to prepare itself to receive all of > those codecs *simultaneously* as the solution to > the problem. The reason here is pragmatic: DSP's > have limited amounts of memory, and many of them > swap codec code in and out of their fast > memory. Therefore saying that the DSP must be able > to simultaneously handle G.729, G.728, G.726 and > G.711 when that is really a set of "choose one" > alternatives is going to cause a whole lot of > implementations to give resource errors instead of > the desired semantics. > > Mike > > Rosen, Brian writes: > > Negotiation is always between two MGCs. Negotiation > always starts with > > capability. So there is a message > > from MGC to MG to ask for capability. It can express > policy, but it doesn't > > have to. Then the two MGCs negotiate. > > Then both MGCs tell their respective MGs what the result > is. One end does > > that right away (the end that > > decides). The other end has to wait for the message from > the distant MGC > > before it can tell its MG. In fast start, > > the terminating MG is the decision maker, so it gets > capability from its MG, > > decides based on what it's MG can do, and what the > originating MGC said the > > originating MG can do, and tells it's MG what to do. > > > > We are bending SDP pretty hard. Having yet another bend > so that you can > > differentiate between "choose one > > of these" and "here is my policy, tell me your capability" > is getting > > pretty bad. This is why I liked using > > remote and local rather than sendonly or Nancy's vertical > bar -- less > > modification to SDP syntax. > > > > Brian > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Wednesday, December 22, 1999 7:51 PM > > To: Rosen, Brian > > Cc: megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > > > > > I've had to think about this a bit, because I have a > couple of problems with > > it. The main problem is that there doesn't seem to be any point of > > convergence -- the terminating MG sends back its version > of Local and Remote > > to its MGC "and then negotiation occurs" (your words). > Negotiation between > > what entities? Does there now have to be another round of > messaging to tell > > the MGs what the MGCs have decided, at the terminating end > as well as at the > > originating end? > > > > Actually, I think I can leave this up to the > implementation. We can simply > > have a rule that the MG echoes back that subset of > whatever the MGC proposes > > that the MG can support. If I want to save a message by > making the final > > decision in the terminating MGC BEFORE sending a message > down to the MG > > that's my business as an MGC implementor. > > > > On your concern about getting capability after policy is > set: you can always > > do an AuditCapability on the termination to start with if > you want to be > > perfect. The reason the MGC imposes policy has to do with > the signalling it > > has received, or resources it is trying to husband. > Knowing more precisely > > the instantaneous capability of the MG isn't going to > change those factors. > > > > -----Original Message----- > > From: Rosen, Brian [SMTP:brosen@fore.com] > > Sent: Wednesday, December 22, 1999 3:10 PM > > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > > Cc: megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > In my view each end independently has policy, each > end independently > > has capability. > > Each end independently applies policy to capability and > ends up with an > > ordered list > > of candidates. The negotiation is then to select the > first candidate that > > both ends > > can support. This results in a single answer, which is > communicated to both > > sides. > > > > Suppose the originating MG can do G.711, G.723 and G.729. > The policy of > > the the MGC > > is G.729, then G.726, then G.711, it won't allow G.723. > Suppose the > > terminating end MG has the same capability but the policy > at its MGC is > > G.711 then G.726, then G.729. > > > > > > So the originating MGC sends 729, 726, 711, the > originating MG responds 729, > > 711. > > The terminating MGC sends 711, 726, 729, the terminating > MG responds 711, > > 726, 729. > > The negotiation occurs. In this case the negotiation > would result in 711, > > and both > > ends would set local and remote to 711. Note that > different MGC-MGC > > protocols would have different rules on how negotiation > proceeded, but all > > of them would start with an ordered list of possibles, > eliminate the ones > > that only one side can support, and select among the > remaining ones. > > > > > > I'm a little bothered by the send policy, get capability. It seems > > backwards to me; if I were > > designing the system, I might be inclined to get a > complete capability, > > filter it by policy and > > then negotiate the result. However, the MG has to reserve > resources for the > > worst case of the alternatives it allows. Therefore, it > wants to know the > > policy so that it does not reserve resources for options > the MGC would not > > allow. On the other (other) hand, making the > > > > MG enforce MGC policy also seems wrong - the MGC > should enforce it's > > own policy. > > So, I'd accept the idea that the MG simply states network, > nothing else, the > > MG responds with capability. The MGC filters that with > policy, negotiates > > it, and then sends the single > > > > result to the MG. The way we have it is okay, and > as I observe, may > > leave the MG with > > more available resource. > > > > Brian > > > > -----Original Message----- > > From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com > > ] > > Sent: Wednesday, December 22, 1999 11:48 AM > > To: Rosen, Brian > > Cc: megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > > > > > Could we take this one step further toward > concreteness? A couple > > of points have been bothering me: how does the MG at the > originating end > > know which alternatives to offer, and at the terminating > end what does the > > MG do with Remote? Furthermore, how does the MGC tell the > MG: "This is what > > you're going to use; we're not negotiating any more."? > > > > I've also realized that unless both send and > receive capabilities > > can be expressed in the same descriptor, there is no way > for the originating > > MG at least to express joint capabilities for asymmetric > connections. We > > may be able to live without this. Certainly the H.323 > crowd would prefer to > > do so, since H.245 and H.323 fastStart both separate > capabilities by > > direction of flow. > > > > These are my answers to my own questions, starting > from the premise > > that Local describes received flows, Remote describes > transmitted flows. > > > > (1) At the originating end, the MGC may supply a > set of alternative > > session descriptions (mutually exclusive alternatives) and > within each a > > list of one or more payload types. Here's the key point: > the MG in its > > response is constrained by the list of payload types -- it > can't offer any > > not listed in the first place by the MGC. However, it can offer > > alternatives for detailed parameters associated with those > payload types. > > This is especially necessary with video, where the list of possible > > alternatives can go on forever. We'll have to think a bit > about the syntax > > for offering these alternatives -- yet more session > descriptions or ranges > > or whatever. > > > > (2) At the terminating end, the MGC takes the > signalled send and > > receive capabilities from the far end. (If the signalling > is via SDP and > > capabilities are not broken out by direction, symmetric > flow capabilities > > are assumed.) The terminating MGC may filter out > non-starters from its > > policy viewpoint, then it will build Local and Remote from > what remains. > > > > Now the question is what rule the MG follows to > evaluate what is > > presented. First off, I assume we want the MG to choose a single > > alternative at this point. How is that indicated by the > MGC? I would > > favour an explicit parameter in LocalControl rather than a > rule like "If > > Remote is present, choose a single alternative rather than > presenting > > alternatives.". > > > > > > > > -----Original Message----- > > From: Rosen, Brian [SMTP:brosen@fore.com] > > Sent: Wednesday, December 22, 1999 10:46 AM > > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > > Cc: Megaco (E-mail) > > Subject: RE: Proposed Text For Media Specification > > > > In defense of the position I would point > out that when the > > MG supplies it's version of local it is BEFORE negotiation > > takes place. This has to be true because it has to reserve > > resources and report what it could support. The MGC must take > > that set of alternatives and negotiate with its opposite MGC. > > The result of that negotiation has to be one, agreed upon session > > description that both MGs can support. > > > > Given that, I think the MG must offer a > set of alternatives. > > > > > > Brian > > > -----Original Message----- > > > From: Tom-PT Taylor [ < mailto:taylor@nortelnetworks.com > > >] > > > Sent: Wednesday, December 22, 1999 10:40 AM > > > To: Chip Sharp; Brian Rosen; megaco@standards.nortelnetworks.com > > > Subject: RE: Proposed Text For Media Specification > > > > > > > > > I'm willing to follow this thought along a bit further. > I think the > > > concrete difference between the viewpoint I've documented and the > > > "policy-capability" viewpoint is this: if the MGC sends down > > > a number of > > > alternative session descriptions, in my case the MG picks > > > one, while in > > > Brian's case the MG replies with all the session > descriptions it can > > > currently support. I am willing to accept the latter > > > proposition if we can > > > all agree on it. From there, I will go forward with Chip's > > > distinction > > > between the roles of Local and Remote, and I think we'll > have a good > > > sensible result. > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > >
> class=090593815-23121999>Negotiation is always between two > MGCs.  > > Negotiation always starts with capability.  So there is a > > message
> >
class=090593815-23121999>from > > MGC to MG to ask for capability.  It can express > policy, but it doesn't > > have to.  Then the two MGCs negotiate.
> >
class=090593815-23121999>Then > > both MGCs tell their respective MGs what the result > is.  One end does that > > right away (the end that
> >
> class=090593815-23121999>decides).  The other end has > to wait for the > > message from the distant MGC before it can tell its > MG.  In fast > > start,
> >
class=090593815-23121999>the > > terminating MG is the decision maker, so it gets > capability from its MG, decides > > based on what it's MG can do, and what the originating MGC > said the originating > > MG can do, and tells it's MG what to do. 
> >
> class=090593815-23121999> 
> >
class=090593815-23121999>We are > > bending SDP pretty hard.  Having yet another bend so > that you can > > differentiate between "choose one
> >
class=090593815-23121999>of > > these" and "here is my policy, tell me your > capability"  is getting pretty > > bad.  This is why I liked using
> >
class=090593815-23121999>remote > > and local rather than sendonly or Nancy's vertical bar -- > less modification to > > SDP syntax.
> >
> class=090593815-23121999> 
> >
> class=090593815-23121999>Brian
> >
> style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; > PADDING-LEFT: 5px"> > >
face=Tahoma > > size=2>-----Original Message-----
From: Tom-PT Taylor > > [mailto:taylor@nortelnetworks.com]
Sent: > Wednesday, December 22, > > 1999 7:51 PM
To: Rosen, Brian
Cc: > > megaco@standards.nortelnetworks.com
Subject: > RE: Proposed Text For > > Media Specification

> >

I've had to > think about this a bit, > > because I have a couple of problems with it.  The > main problem is that > > there doesn't seem to be any point of convergence -- the > terminating MG sends > > back its version of Local and Remote to its MGC "and > then negotiation occurs" > > (your words).  Negotiation between what > entities?  Does there now > > have to be another round of messaging to tell the MGs > what the MGCs have > > decided, at the terminating end as well as at the > originating end?

> >

Actually, I > think I can leave this up > > to the implementation.  We can simply have a rule > that the MG echoes back > > that subset of whatever the MGC proposes that the MG can > support.  If I > > want to save a message by making the final decision in > the terminating MGC > > BEFORE sending a message down to the MG that's my > business as an MGC > > implementor.

> >

On your concern > about getting > > capability after policy is set: you can always do an > AuditCapability on the > > termination to start with if you want to be > perfect.  The reason the MGC > > imposes policy has to do with the signalling it has > received, or resources it > > is trying to husband.  Knowing more precisely the > instantaneous > > capability of the MG isn't going to change those > factors.

> >
    > >

    -----Original > Message-----
    > face=Arial size=1>From:   > size=1>Rosen, Brian [SMTP:brosen@fore.com] >
    > size=1>Sent:   size=1>Wednesday, > > December 22, 1999 3:10 PM
    > size=1>To:     > size=1>Taylor, Tom-PT [CAR:B904-I:EXCH] >
    > size=1>Cc:     > size=1>megaco@standards.nortelnetworks.com >
    > > size=1>Subject:        T> > face=Arial size=1>RE: Proposed Text For Media > Specification

    > >

    In my view > each end independently > > has policy, each end independently has > capability.
    > color=#0000ff face=Arial size=2>Each end independently > applies policy to > > capability and ends up with an ordered list >
    > face=Arial size=2>of candidates.  The negotiation > is then to select the > > first candidate that both ends
    color=#0000ff face=Arial > > size=2>can support.  This results in a single > answer, which is > > communicated to both sides.
    face=Arial>  > >
    Suppose the > originating MG can do > > G.711, G.723 and G.729.   The policy of the > the MGC > >
    is G.729, > then G.726, then G.711, > > it won't allow G.723.  Suppose the terminating > end MG has the same > > capability but the policy at its MGC is G.711 then G.726, then > > G.729.

    > >

     
    color=#0000ff face=Arial > > size=2>So the originating MGC sends 729, 726, 711, the > originating MG > > responds 729, 711.
    face=Arial size=2>The > > terminating MGC sends 711, 726, 729, the terminating > MG responds 711, 726, > > 729.
    size=2>The negotiation > > occurs.  In this case the negotiation would > result in 711, and > > both
    size=2>ends would set local > > and remote to 711.  Note that different MGC-MGC > protocols would have > > different rules on how negotiation proceeded, but all > of them would start > > with an ordered list of possibles, eliminate the ones > that only one side can > > support, and select among the remaining ones.

    > >

     
    color=#0000ff face=Arial > > size=2>I'm a little bothered by the send policy, get > capability.  It > > seems backwards to me;  if I were >
    > face=Arial size=2>designing the system, I might be > inclined to get a > > complete capability, filter it by policy and >
    > face=Arial size=2>then negotiate the result.  > However, the MG has to > > reserve resources for the worst case of the > alternatives it allows.  > > Therefore, it wants to know the policy so that it > does not reserve > > resources for options the MGC would not allow.  > On the other (other) > > hand, making the

    > >

    MG enforce > MGC policy also seems > > wrong - the MGC should enforce it's own policy. >
    > color=#0000ff face=Arial size=2>So, I'd accept the > idea that the MG simply > > states network, nothing else, the MG responds with > capability.  The MGC > > filters that with policy, negotiates it, and then sends the > > single

    > >

    result to the > MG.  The way we > > have it is okay, and as I observe, may leave the MG > with
    > color=#0000ff face=Arial size=2>more available > resource.
    > face=Arial> 
    > size=2>Brian

    > >
      > >

      -----Original > Message-----
       > face=Tahoma size=2>From: size=2> Tom-PT Taylor > > [ > > href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelne > tworks.com > face=Tahoma size=2>]
       > size=2>Sent: > Wednesday, December 22, > > 1999 11:48 AM
       size=2>To: > face=Tahoma size=2> Rosen, Brian
       face=Tahoma > > size=2>Cc: > > > megaco@standards.nortelnetworks.com
       > size=2>Subject: > RE: Proposed Text For > > Media Specification

      > >

      Could we > take this one step > > further toward concreteness?  A couple of > points have been bothering > > me: how does the MG at the originating end know > which alternatives to > > offer, and at the terminating end what does the MG > do with Remote?  > > Furthermore, how does the MGC tell the MG: "This is > what you're going to > > use; we're not negotiating any more."?

      > >

      I've also > realized that unless > > both send and receive capabilities can be expressed > in the same > > descriptor, there is no way for the originating MG > at least to express > > joint capabilities for asymmetric connections.  > We may be able to > > live without this.  Certainly the H.323 crowd > would prefer to do so, > > since H.245 and H.323 fastStart both separate > capabilities by direction of > > flow.

      > >

      These are > my answers to my own > > questions, starting from the premise that Local > describes received flows, > > Remote describes transmitted flows.

      > >

      (1) At the > originating end, the > > MGC may supply a set of alternative session > descriptions (mutually > > exclusive alternatives) and within each a list of > one or more payload > > types.  Here's the key point: the MG in its > response is constrained > > by the list of payload types -- it can't offer any > not listed in the first > > place by the MGC.  However, it can offer > alternatives for detailed > > parameters associated with those payload > types.  This is especially > > necessary with video, where the list of possible > alternatives can go on > > forever.  We'll have to think a bit about the > syntax for offering > > these alternatives -- yet more session descriptions > or ranges or > > whatever.

      > >

      (2) At the > terminating end, the > > MGC takes the signalled send and receive > capabilities from the far > > end.  (If the signalling is via SDP and > capabilities are not broken > > out by direction, symmetric flow capabilities are > assumed.)  The > > terminating MGC may filter out non-starters from its > policy viewpoint, > > then it will build Local and Remote from what > remains.

      > >

      Now the > question is what rule the > > MG follows to evaluate what is presented.  > First off, I assume we > > want the MG to choose a single alternative at this > point.  How is > > that indicated by the MGC?  I would favour an > explicit parameter in > > LocalControl rather than a rule like "If Remote is > present, choose a > > single alternative rather than presenting > > alternatives.".



      > >

              face=Arial > > size=1>-----Original Message----- > face=Arial>
       > size=1>From:   > > face=Arial size=1>Rosen, Brian > [SMTP:brosen@fore.com] > face=Arial>
       > size=1>Sent:   > > face=Arial size=1>Wednesday, December 22, 1999 10:46 > AM > face=Arial>
       > size=1>To:     face=Arial> > > Taylor, Tom-PT > > [CAR:B904-I:EXCH] face=Arial>
       > size=1>Cc:     face=Arial> > > Megaco (E-mail) > face=Arial>
       > > size=1>Subject:        T> > face=Arial> RE: > Proposed Text For Media > > Specification

      > >

              face=Arial size=2>In > > defense of the position I would point out that when > the > face=Arial>
      MG > supplies it's version of > > local it is BEFORE negotiation face=Arial>
       > face=Arial size=2>takes place.  This has to be > true because it has to > > reserve
       > size=2>resources and report what it could > support.  The MGC must > > take
       face=Arial size=2>that set of > > alternatives and negotiate with its opposite MGC. > face=Arial>
      The > result of that > > negotiation has to be one, agreed upon session > face=Arial>
       size=2>description that both MGs > > can support.

      > >

              face=Arial > > size=2>Given that, I think the MG must offer a set of > > alternatives.

      > >

              face=Arial > > size=2>Brian
       face=Arial > > size=2>> -----Original Message----- > face=Arial>
      > > From: Tom-PT Taylor > > [ < > > href="mailto:taylor@nortelnetworks.com">mailto:taylor@nortelne > tworks.com> > face=Arial size=2>] face=Arial>
       > size=2>> Sent: Wednesday, December 22, 1999 10:40 > AM > face=Arial>
      > > To: Chip Sharp; Brian > > Rosen; megaco@standards.nortelnetworks.com > face=Arial>
      > > Subject: RE: Proposed > > Text For Media Specification face=Arial>
       > face=Arial size=2>>
      > size=2>>
      > > I'm willing to follow > > this thought along a bit further.  I think > the > face=Arial>
      > > concrete difference > > between the viewpoint I've documented and the > face=Arial>
      > > "policy-capability" > > viewpoint is this: if the MGC sends > down
      > size=2>> a number of face=Arial>
       > size=2>> alternative session descriptions, in my > case the MG > > picks
      > one, > while in > face=Arial>
      > > Brian's case the MG > > replies with all the session descriptions it can > face=Arial>
      > currently > > support.  I am willing to accept the > latter
      > face=Arial size=2>> proposition if we can > face=Arial>
      > > all agree on it.  > > From there, I will go forward with > Chip's
      > size=2>> distinction face=Arial>
       > size=2>> between the roles of Local and Remote, > and I think we'll have > > a good
       face=Arial size=2>> > > sensible result. face=Arial>
       > size=2>>

> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 10:54:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03193 for ; Mon, 3 Jan 2000 10:54:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.598FD030@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:43:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102433 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 10:41:34 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5085380@standards.nortelnetworks.com>; Mon, 3 Jan 2000 10:31:34 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA20451; Mon, 3 Jan 2000 10:41:46 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA29164; Mon, 3 Jan 2000 10:41:47 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 10:39:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685AD@whq-msgusr-02.fore.com> Date: Mon, 3 Jan 2000 10:41:45 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification] X-To: Christian Groves , Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM See comments below > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Monday, January 03, 2000 10:31 AM > To: Tom-PT Taylor; Brian Rosen > Cc: ietf_megaco > Subject: Re: Proposed Text For Media Specification] > > > G'Day Brian and Tom, > > Negotiation is between two MGCs - I agree. > Negotiation always starts with capability - I agree. > There is a message from the MGC to MG to ask for capability - > hummm.... > The MGC can be provisioned with the MGs capabilities or it > can ask using > the AuditCap command. Its the MGC that should order the MG to > do certain > task with the capabilties and the associated resources. [br]Well, the issue we are dealing with is reservation of resources. AuditCap doesn't get you that. There is (currently) no way to do it. The proposal is that when the MG offers it's first Local/Remote descriptor, it reserves the resources at that time. When the MGC subsequently modifies local/remote to reflect the results of the negotiation, then the resources are committed (and any unused, but reserved resources are released). > > for example the fast start. > 1. The initiating MGC has a certain set of capabilities. It > knows the MG > can do these based on pre-provisioning or AuditCap. [br]No, the MGC doesn't know because AuditCap doesn't reserve resources, so the sequence: AuditCap (for context c1) AuditCap (for context c2) Context=c1{Add Context=c2(Add can fail. In particular, if the sequence was AuditCap (for context c1) Context=c1{Add AuditCap (for context c2) Context=c2(Add the results returned for the second Audit Cap can be different. > 2. Because of fast start the orginating MGC orders its MG to 'RESERVE' > resources for reception of media streams according to the > capabilities. [br]This could fail as noted above. If the MGC reserves resources for c1, and then tries to reserve the same resource again for c2, it may fail. > 3. The initiating MGC using H245 negotiates with the > terminating MGC the > capabilities. As the terminating MGC is the 'terminating side' it does > one of two options. The choice between options is implementation > specific. > option a) it decides the capability and then orders the MG to > send media > with a certain capability. > option b) sends the set of capabilities (ie. overspecified properties) > asking the MG to 'CHOOSE' one set of capabilties and immediately > 'RESERVE' resources for the sending of media. [br]There is no reservation really here; the MG makes a real choice, and actually consumes the resources. > 4. In this case the media beats the MGC-MGC negotiation. The > originating > side according to Faststart must expect media as soon as its send the > embedded H245 OLC. > 5. The originating MG detects media on one set of resources > and NOTIFYs > the MGC. [br]This is not in any call flows to date and there is no event defined for recieving media on a flow. > 6. The MGC then does a MODIFY removing the other allocated resources. > > I don't believe that the negotiation between MGCs should be covered in > Megaco. I don't Below is some proposed text that I believe most of the > concepts discussed without going in the nuts and bolts of SDP. [br] I've not thought through this text since I think the premise is wrong. I think the faststart sequence is: MGC1 sends policy to MG1 in local MG1 responds with capability, filtered by policy, and reserves resources MGC1 sends capability to MGC2 MGC2 sends policy to MG2 MG2 responds with either capability, or simply makes a choice and responds with the choice MGC2 sends negotiated result to MGC1 MGC1 modifies MG1 with result. Resources are committed, excess ones are released. Since media may arrive at MG1 prior to the last step above, MG1 must be capable of configuring itself based on what it gets. This is what a fast-start capable GW has to do now. > Below is a start of a proposal for 7.1.8 Local and Remote > Start>>>>> > Local and Remote Descriptors contain the parameters > describing the flows > sent to and received from the MG. In the case where the MGC > controls the > originating MG. The Local Descriptor contains the parameters > describing > the flows received by the originating gateway and sent by the remote > gateway. The Remote Descriptor contains the parameters > describing flows > sent by the originating gateway and received by the Remote gateway. > > > Local and Remote descriptors may contain sets of parameters > to describe > different capability sets. In the text version this is achieved by > <<>>. In the binary version this is achieved by . > > H.248 supports three uses of the Local and Remote Descriptors between > the MGC and MG: > 1. The MGC shall 'fully specify' the parameters describing the flows > associated with the descriptors. The MG shall reserve and use the > resources specified by the MGC. > 2. The MGC shall order the MG to 'reserve' the resources associated > with EACH set of parameters (ie. Capability sets) describing the flows > associated with the descriptors. The MG shall reserve and use the > resources specified by each set of parameters as specified by the MGC. > In the text version this is achieved by . > In the binary version this is achieved by . > 3. The MGC shall order the MG to 'choose' the resources > associated with > one set of parameters (ie. Capability sets) describing the flows > associated with the descriptors. The MG shall choose, reserve and use > the resources specified by one set of parameters as specified > by the the > MGC. > In the text version this is achieved by . > In the binary version this is achieved by . > <<< END > > We may also want to add some text on what descriptors and > errors the MG > returns in line with Tom's proposal. Is this something we can > work with? > > Cheers, Christian > > -------- Original Message -------- > Subject: Re: Proposed Text For Media Specification > Date: Thu, 23 Dec 1999 10:55:33 -0500 > From: "Rosen, Brian" > Reply-To: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Negotiation is always between two MGCs. Negotiation always > starts with > capability. So there is a messagefrom MGC to MG to ask for > capability. > It can express policy, but it doesn't have to. Then the two MGCs > negotiate.Then both MGCs tell their respective MGs what the result is. > One end does that right away (the end thatdecides). The other end has > to wait for the message from the distant MGC before it can > tell its MG. > In fast start,the terminating MG is the decision maker, so it gets > capability from its MG, decides based on what it's MG can do, and what > the originating MGC said the originating MG can do, and tells it's MG > what to do. We are bending SDP pretty hard. Having yet > another bend so > that you can differentiate between "choose oneof these" and > "here is my > policy, tell me your capability" is getting pretty bad. > This is why I > liked usingremote and local rather than sendonly or Nancy's > vertical bar > -- less modification to SDP syntax.Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, December 22, 1999 7:51 PM > To: Rosen, Brian > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > I've had to think about this a bit, because I have a couple of > problems with it. The main problem is that there doesn't seem > to be any point of convergence -- the terminating MG sends > back its version of Local and Remote to its MGC "and then > negotiation occurs" (your words). Negotiation between what > entities? Does there now have to be another round of > messaging to tell the MGs what the MGCs have decided, at the > terminating end as well as at the originating end? > > Actually, I think I can leave this up to the implementation. > We can simply have a rule that the MG echoes back that subset > of whatever the MGC proposes that the MG can support. If I > want to save a message by making the final decision in the > terminating MGC BEFORE sending a message down to the MG that's > my business as an MGC implementor. > > On your concern about getting capability after policy is set: > you can always do an AuditCapability on the termination to > start with if you want to be perfect. The reason the MGC > imposes policy has to do with the signalling it has received, > or resources it is trying to husband. Knowing more precisely > the instantaneous capability of the MG isn't going to change > those factors. > > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Wednesday, December 22, 1999 3:10 PM > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > In my view each end independently has policy, each end > independently has capability. > Each end independently applies policy to capability and > ends up with an ordered list > of candidates. The negotiation is then to select the > first candidate that both ends > can support. This results in a single answer, which is > communicated to both sides. > > Suppose the originating MG can do G.711, G.723 and > G.729. The policy of the the MGC > is G.729, then G.726, then G.711, it won't allow G.723. > Suppose the terminating end MG has the same capability > but the policy at its MGC is G.711 then G.726, then > G.729. > > > So the originating MGC sends 729, 726, 711, the > originating MG responds 729, 711. > The terminating MGC sends 711, 726, 729, the terminating > MG responds 711, 726, 729. > The negotiation occurs. In this case the negotiation > would result in 711, and both > ends would set local and remote to 711. Note that > different MGC-MGC protocols would have different rules on > how negotiation proceeded, but all of them would start > with an ordered list of possibles, eliminate the ones > that only one side can support, and select among the > remaining ones. > > > I'm a little bothered by the send policy, get > capability. It seems backwards to me; if I were > designing the system, I might be inclined to get a > complete capability, filter it by policy and > then negotiate the result. However, the MG has to > reserve resources for the worst case of the alternatives > it allows. Therefore, it wants to know the policy so > that it does not reserve resources for options the MGC > would not allow. On the other (other) hand, making the > > MG enforce MGC policy also seems wrong - the MGC should > enforce it's own policy. > So, I'd accept the idea that the MG simply states > network, nothing else, the MG responds with capability. > The MGC filters that with policy, negotiates it, and then > sends the single > > result to the MG. The way we have it is okay, and as I > observe, may leave the MG with > more available resource. > > Brian > -----Original Message----- > From: Tom-PT Taylor > [mailto:taylor@nortelnetworks.com] > Sent: Wednesday, December 22, 1999 11:48 AM > To: Rosen, Brian > Cc: megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > > Could we take this one step further toward > concreteness? A couple of points have been > bothering me: how does the MG at the originating end > know which alternatives to offer, and at the > terminating end what does the MG do with Remote? > Furthermore, how does the MGC tell the MG: "This is > what you're going to use; we're not negotiating any > more."? > > I've also realized that unless both send and receive > capabilities can be expressed in the same > descriptor, there is no way for the originating MG > at least to express joint capabilities for > asymmetric connections. We may be able to live > without this. Certainly the H.323 crowd would > prefer to do so, since H.245 and H.323 fastStart > both separate capabilities by direction of flow. > > These are my answers to my own questions, starting > from the premise that Local describes received > flows, Remote describes transmitted flows. > > (1) At the originating end, the MGC may supply a set > of alternative session descriptions (mutually > exclusive alternatives) and within each a list of > one or more payload types. Here's the key point: > the MG in its response is constrained by the list of > payload types -- it can't offer any not listed in > the first place by the MGC. However, it can offer > alternatives for detailed parameters associated with > those payload types. This is especially necessary > with video, where the list of possible alternatives > can go on forever. We'll have to think a bit about > the syntax for offering these alternatives -- yet > more session descriptions or ranges or whatever. > > (2) At the terminating end, the MGC takes the > signalled send and receive capabilities from the far > end. (If the signalling is via SDP and capabilities > are not broken out by direction, symmetric flow > capabilities are assumed.) The terminating MGC may > filter out non-starters from its policy viewpoint, > then it will build Local and Remote from what > remains. > > Now the question is what rule the MG follows to > evaluate what is presented. First off, I assume we > want the MG to choose a single alternative at this > point. How is that indicated by the MGC? I would > favour an explicit parameter in LocalControl rather > than a rule like "If Remote is present, choose a > single alternative rather than presenting > alternatives.". > > > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Wednesday, December 22, 1999 10:46 AM > To: Taylor, Tom-PT [CAR:B904-I:EXCH] > Cc: Megaco (E-mail) > Subject: RE: Proposed Text For Media > Specification > > In defense of the position I would point out > that when the > MG supplies it's version of local it is BEFORE > negotiation > takes place. This has to be true because it has to > reserve > resources and report what it could support. The MGC > must take > that set of alternatives and negotiate with its > opposite MGC. > The result of that negotiation has to be one, agreed > upon session > description that both MGs can support. > > Given that, I think the MG must offer a set > of alternatives. > > Brian > > -----Original Message----- > > From: Tom-PT Taylor [ > ] > > Sent: Wednesday, December 22, 1999 10:40 AM > > To: Chip Sharp; Brian Rosen; > megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > > > > I'm willing to follow this thought along a bit > further. I think the > > concrete difference between the viewpoint I've > documented and the > > "policy-capability" viewpoint is this: if the MGC > sends down > > a number of > > alternative session descriptions, in my case the > MG picks > > one, while in > > Brian's case the MG replies with all the session > descriptions it can > > currently support. I am willing to accept the > latter > > proposition if we can > > all agree on it. From there, I will go forward > with Chip's > > distinction > > between the roles of Local and Remote, and I think > we'll have a good > > sensible result. > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 11:32:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03838 for ; Mon, 3 Jan 2000 11:32:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB3AD970@standards.nortelnetworks.com>; Mon, 3 Jan 2000 11:21:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102481 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 11:20:58 -0500 Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B577770@standards.nortelnetworks.com>; Mon, 3 Jan 2000 11:20:57 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA28586; Mon, 3 Jan 2000 08:46:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA19712; Mon, 3 Jan 2000 08:31:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF0685AB@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14448.52941.88185.750021@thomasm-u1.cisco.com> Date: Mon, 3 Jan 2000 08:31:09 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685AB@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Rosen, Brian writes: > The "reserve" is worst case resource, not simultaneous. > So if the DSP is already running G.726, and G.723 takes > fewer DSP cycles than G.729, if the MG offers G.726, G.723, G.729, > it would have to reserve enough DSP cycles to do G.729. > We will have to be careful about wording to make this clear. I think you're missing my point. It's not just CPU cycles, it's memory too. In order to simultaneously decode all of the proposed coders, you need them loaded into memory. That's a bad assumption. What the semantics here really want to be is "I'm willing to load any one of these once you choose" or "I've loaded this one, but am willing to load these others if you can't support it." Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 11:58:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04148 for ; Mon, 3 Jan 2000 11:58:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4E732EF0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 11:47:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102513 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 11:46:02 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B69D5C50@standards.nortelnetworks.com>; Mon, 3 Jan 2000 11:36:02 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA26766; Mon, 3 Jan 2000 11:46:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA18780; Mon, 3 Jan 2000 11:46:15 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 11:43:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685BC@whq-msgusr-02.fore.com> Date: Mon, 3 Jan 2000 11:46:14 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM The requirement would be that the MG reserve enough memory to support ANY, not ALL. So, if the G.723 codec was the biggest memory hog, but the G.729 was the biggest cycle hog, the MG would have to reserve enough memory for .723, and enough cycles for .729. If there were any other resources, it would have to do a similar thing - reserve enough resources so that it can support any of the options it offers. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 03, 2000 11:31 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Proposed Text For Media Specification > > > Rosen, Brian writes: > > The "reserve" is worst case resource, not simultaneous. > > So if the DSP is already running G.726, and G.723 takes > > fewer DSP cycles than G.729, if the MG offers G.726, G.723, G.729, > > it would have to reserve enough DSP cycles to do G.729. > > We will have to be careful about wording to make this clear. > > I think you're missing my point. It's not just > CPU cycles, it's memory too. In order to simultaneously > decode all of the proposed coders, you need them loaded > into memory. That's a bad assumption. What the semantics > here really want to be is "I'm willing to load any one > of these once you choose" or "I've loaded this one, but am > willing to load these others if you can't support it." > > Mike > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 13:49:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05973 for ; Mon, 3 Jan 2000 13:49:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE4423A0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 13:38:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102760 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 13:37:10 -0500 Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2BA0D30@standards.nortelnetworks.com>; Mon, 3 Jan 2000 13:37:10 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA17323; Mon, 3 Jan 2000 10:41:24 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA19727; Mon, 3 Jan 2000 10:47:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14448.61112.698390.595703@thomasm-u1.cisco.com> Date: Mon, 3 Jan 2000 10:47:20 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: > I'm willing to follow this thought along a bit further. I think the > concrete difference between the viewpoint I've documented and the > "policy-capability" viewpoint is this: if the MGC sends down a number of > alternative session descriptions, in my case the MG picks one, while in > Brian's case the MG replies with all the session descriptions it can > currently support. I am willing to accept the latter proposition if we can > all agree on it. From there, I will go forward with Chip's distinction > between the roles of Local and Remote, and I think we'll have a good > sensible result. Aside from the issue of not wanting to recreate syntax when you could use SDP to do the same, there are three constraints which we must adhere to: 1) Negotiation must happen with a three way handshake between the MGC and the two MG's: eg Add(o)/Add(t)/Modify(o) I think that Tom's original proposal does not meet this requirement, though Brian's does. 2) MG's which offer the set of codec alternatives in Brian's proposal MUST NOT be expected to have those coders actually loaded and prepared to process media packets. The MG will only prepare itself for receipt of packets when it sees a single choice. 3) The entire process MUST NOT lead to front end clipping. I'm not sure how you do this given the other constraints other than making it into a 4 way handshake. Maybe somebody more clever than me can solve that problem. Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 14:30:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06372 for ; Mon, 3 Jan 2000 14:30:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A8F9F80@standards.nortelnetworks.com>; Mon, 3 Jan 2000 14:19:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102799 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 14:17:35 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E225DF90@standards.nortelnetworks.com>; Mon, 3 Jan 2000 14:07:34 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA07817; Mon, 3 Jan 2000 14:17:46 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA26283; Mon, 3 Jan 2000 14:17:48 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 3 Jan 2000 14:15:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685BE@whq-msgusr-02.fore.com> Date: Mon, 3 Jan 2000 14:17:46 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM Well at least one more person is as confused as I am about how fast start works. I assume that if you get media before you get the MGC message that tells you what was negotiated, you look at the RTP header to figure out what format the data is in, and start decoding. Is that right? If true, it means if you see media before the modify, then you start decoding, and if the modify says something different than you implied from the header, it's an error. It isn't necessary to wait until you get the modify before you can process the media. I suppose that since there is the possibility of asymmetric coding, you can't send any media until you have the modify. Anyway, I agree, 3 commands, the original add, which might have policy, who's response is capability, the add to the terminating MG, which responds with it's (single) choice, and the modify that at the originating MG that tells it the single negotiated result. HOWEVER, this means we need syntax to differentiate between an add with policy, respond with capability, and add with policy, choose one and respond with your choice. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 03, 2000 1:47 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Proposed Text For Media Specification > > > Tom-PT Taylor writes: > > I'm willing to follow this thought along a bit further. I > think the > > concrete difference between the viewpoint I've documented and the > > "policy-capability" viewpoint is this: if the MGC sends > down a number of > > alternative session descriptions, in my case the MG picks > one, while in > > Brian's case the MG replies with all the session > descriptions it can > > currently support. I am willing to accept the latter > proposition if we can > > all agree on it. From there, I will go forward with > Chip's distinction > > between the roles of Local and Remote, and I think we'll > have a good > > sensible result. > > Aside from the issue of not wanting to recreate > syntax when you could use SDP to do the same, > there are three constraints which we must adhere > to: > > 1) Negotiation must happen with a three way handshake > between the MGC and the two MG's: eg Add(o)/Add(t)/Modify(o) > I think that Tom's original proposal does not meet this > requirement, though Brian's does. > > 2) MG's which offer the set of codec alternatives in > Brian's proposal MUST NOT be expected to have those > coders actually loaded and prepared to process media > packets. The MG will only prepare itself for receipt > of packets when it sees a single choice. > > 3) The entire process MUST NOT lead to front end clipping. > I'm not sure how you do this given the other constraints > other than making it into a 4 way handshake. Maybe somebody > more clever than me can solve that problem. > > > Mike > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 15:25:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07014 for ; Mon, 3 Jan 2000 15:25:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FD8EC20@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:13:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102935 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 15:12:47 -0500 Received: from witbier.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FDD111C0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 15:12:46 -0500 Received: from mramalho-nt1 (ssh.cisco.com [171.69.10.34]) by witbier.cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id MAA07094; Mon, 3 Jan 2000 12:22:07 -0800 (PST) X-Sender: mramalho@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000103150115.009fff10@localhost> Date: Mon, 3 Jan 2000 15:22:25 -0500 Reply-To: "Michael A. Ramalho" Sender: "Media Gateway Control (megaco)" From: "Michael A. Ramalho" Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" X-cc: jim.toga@metatel.com, dskran@lucent.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685BE@whq-msgusr-02.fore. com> Brian, [We need a FastStart expert here ... but ... I think that you got it "almost" right]. When FastStart succeeds, any early media toward the originator will have a RTP codec type that you "expect", thus you can happily decode before receiving the modify. (You expect the modify to correspond to the codec type that you sent as a choice, including any dynamically assigned codec types). But FastStart is allowed to fail (in my limited understanding of the spec) .... for example the originator requests codec A, B, or C and the receiver cannot use A, B, or C ... but desires D, E, or F. In this case the RTP header may or may not provide sufficient information for you to determine the codec type (if a static codec type was chosen, you could know). For the dynamic codec type case the originator must wait for the result of the (normal, non-FastStart) codec negotiation to complete to know what it can encode with. Is this correct? If so, can receiver with "early media" code with D, E, or F (I don't think so) .... or does it wait until the full outcome of the codec negotiation process before sending any media (I think this). [Jim Toga or Dale Skran where are you? ... copying you both on this]. Michael Ramalho At 02:17 PM 1/3/00 -0500, Rosen, Brian wrote: >Well at least one more person is as confused as I am about how >fast start works. > >I assume that if you get media before you get the MGC message that >tells you what was negotiated, you look at the RTP header to figure out what >format the data is in, and start decoding. Is that right? > >If true, it means if you see media before the modify, then you >start decoding, and if the modify says something different than >you implied from the header, it's an error. It isn't necessary to >wait until you get the modify before you can process the media. >I suppose that since there is the possibility of asymmetric coding, >you can't send any media until you have the modify. > >Anyway, I agree, 3 commands, the original add, which might have >policy, who's response is capability, the add to the terminating >MG, which responds with it's (single) choice, and the modify that at the >originating MG that tells it the single negotiated result. > >HOWEVER, this means we need syntax to differentiate between an >add with policy, respond with capability, and add with policy, >choose one and respond with your choice. > >Brian > >> -----Original Message----- >> From: Michael Thomas [mailto:mat@cisco.com] >> Sent: Monday, January 03, 2000 1:47 PM >> To: MEGACO@standards.nortelnetworks.com >> Subject: Re: Proposed Text For Media Specification >> >> >> Tom-PT Taylor writes: >> > I'm willing to follow this thought along a bit further. I >> think the >> > concrete difference between the viewpoint I've documented and the >> > "policy-capability" viewpoint is this: if the MGC sends >> down a number of >> > alternative session descriptions, in my case the MG picks >> one, while in >> > Brian's case the MG replies with all the session >> descriptions it can >> > currently support. I am willing to accept the latter >> proposition if we can >> > all agree on it. From there, I will go forward with >> Chip's distinction >> > between the roles of Local and Remote, and I think we'll >> have a good >> > sensible result. >> >> Aside from the issue of not wanting to recreate >> syntax when you could use SDP to do the same, >> there are three constraints which we must adhere >> to: >> >> 1) Negotiation must happen with a three way handshake >> between the MGC and the two MG's: eg Add(o)/Add(t)/Modify(o) >> I think that Tom's original proposal does not meet this >> requirement, though Brian's does. >> >> 2) MG's which offer the set of codec alternatives in >> Brian's proposal MUST NOT be expected to have those >> coders actually loaded and prepared to process media >> packets. The MG will only prepare itself for receipt >> of packets when it sees a single choice. >> >> 3) The entire process MUST NOT lead to front end clipping. >> I'm not sure how you do this given the other constraints >> other than making it into a 4 way handshake. Maybe somebody >> more clever than me can solve that problem. >> >> >> Mike >> > Michael A. Ramalho, Ph.D. Cisco Systems 1802 Rue de la Port Wall Township, NJ 07719-3784 Office email: mramalho@cisco.com Personal email: mar42@cornell.edu Office: +1.732.449.5762 Cell: +1.732.809.0188 Pager: +1.800.365.4578 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 17:25:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08391 for ; Mon, 3 Jan 2000 17:25:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F86B300@standards.nortelnetworks.com>; Mon, 3 Jan 2000 17:14:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103104 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 17:13:05 -0500 Received: from mail.pi.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBE26A40@standards.nortelnetworks.com>; Mon, 3 Jan 2000 17:13:04 -0500 Received: from pigpen (ap01-119.mp.pi.se [195.7.86.119]) by mail.pi.se (8.8.8/8.8.8) with SMTP id XAA18802; Mon, 3 Jan 2000 23:23:13 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Message-ID: Date: Mon, 3 Jan 2000 23:22:05 +0100 Reply-To: Gunnar Hellstrom Sender: "Media Gateway Control (megaco)" From: Gunnar Hellstrom Subject: Re: Property types and parameter types X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685AA@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 8bit We have to make up our minds here. If Enumeration is interpreted as it is written in the info on Packages in 12.1.2, it would be allowed to select a list from the possible values. I need that definition in a number of places, and I believe others do it also. Isn´t it a need to specify a number of different tones to listen for out of a richer Enumeration or List of all defined tones? That would be a Sub-list as I understand it. -- In 12.2, the definition of Enumeration is more strict and allows only ONE value out of the enumeration. There is no definition of a Sub-list. So, is there agreement on that the definitions from 12.2 should also be in 12.1.2 with further clarification of Sub-list from below? Regards Gunnar Hellstrom > -----Original Message----- > From: Rosen, Brian [mailto:brosen@fore.com] > Sent: Monday, January 03, 2000 4:20 PM > To: 'Gunnar Hellstrom'; MEGACO@standards.nortelnetworks.com > Subject: RE: Property types and parameter types > > > I had not been aware anyone wanted "sub lists". > > If we REALLY need it, we should put it in, and as you observe, > it should be the same in 12.1.2 and 12.2. > > Brian > > > -----Original Message----- > > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@OMNITOR.SE] > > Sent: Wednesday, December 29, 1999 5:47 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Property types and parameter types > > > > > > In the work with packages, I have hit a little inconsistency > > that I would > > like to have clarified: > > > > There is a difference in H.248 version 12 between the types valid for > > properties and the types valid for parameters. > > Among property types, "Lists or sub-list" and "Boolean" are > > missing. The > > definition of Enumeration is also different: 12.1.2 Indicates "List of > > possible values" while 12.2 indicates "One of a list of > > possible unique > > values". > > > > I suggest that the types defined for parameters in 12.2 is > > copied also to > > 12.1.2. > > > > Specifically I have a need to distinguish between > > > > 1) One value from an Enumeration. I intend to call that type > > "Enumeration". > > > > 2) A selection of one or more values from an Enumeration. I > > intend to call > > that type "sub-list" > > > > Is this according to general understanding? > > > > Examples: > > > > Property Call types > > Type: Sub-list > > Possible Values: > > fax > > text > > data > > Description: > > A set of enabled call types monitored for in the call type > > discrimination > > package. > > (may be set to "fax, text" if we are only interested in > > supporting these > > types) > > > > > > Property Call type > > Type: Enumeration > > Possible values: > > fax > > text > > data > > Description: > > One specific call type that is selected or detected. > > ( may be set to "text" during a text conversation call ) > > > > Is it allowed to do as in the example, to enumerate the > > possible values for > > the members in the sub-list under "Possible values" ? > > > > > > Regards > > Gunnar > > ______________________________________ > > Gunnar Hellström > > Omnitor AB > > Alsnögatan 7, 4tr > > S-116 41 Stockholm > > Sweden > > > > Mob +46 708 204 288 > > Tel +46 8 556 002 03 > > Fax +46 8 556 002 06 > > Video +46 8 556 002 05 > > Txt (All kinds) +46 8 556 002 05 > > E-mail gunnar.hellstrom@omnitor.se > > WWW: http://www.omnitor.se > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 3 18:23:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08926 for ; Mon, 3 Jan 2000 18:23:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2DC11100@standards.nortelnetworks.com>; Mon, 3 Jan 2000 18:13:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103199 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 3 Jan 2000 18:11:14 -0500 Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBD5C2E0@standards.nortelnetworks.com>; Mon, 3 Jan 2000 18:11:14 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA01378; Mon, 3 Jan 2000 15:36:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA19777; Mon, 3 Jan 2000 15:21:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF0685BE@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14449.12021.201927.586529@thomasm-u1.cisco.com> Date: Mon, 3 Jan 2000 15:21:25 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685BE@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Rosen, Brian writes: > If true, it means if you see media before the modify, then you > start decoding, and if the modify says something different than > you implied from the header, it's an error. It isn't necessary to > wait until you get the modify before you can process the media. > I suppose that since there is the possibility of asymmetric coding, > you can't send any media until you have the modify. That's what I was afraid of. This implies that either you load all of the proposed codecs (not just account for their maximum MIPS and ram as you implied), or you better be able to load the codec PDQ once you see the first media packet. A worse problem is if you want to negotiate cipher suites with payload encryption. There, unless cipher suite negotiation is tied to the type field somehow (it is not in packetcable, as one data point), you have no clue how the packet is encrypted, which effectively causes front end clipping too. Since a 4-way handshake is a pretty heinous necessity, maybe the right thing to do would be to buffer the packets in the playback buffer and not process them until the last Modify came in -- this gives the whole playback delay for the arrival of the Modify before you had to drop the packets on the head of the queue. > HOWEVER, this means we need syntax to differentiate between an > add with policy, respond with capability, and add with policy, > choose one and respond with your choice. Isn't this where Local and Remote come into play? If I see several choices in Remote (eg the other side's local), isn't that the trigger for me to choose one? Or am I all screwed up here? Mike > > Brian > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Monday, January 03, 2000 1:47 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Proposed Text For Media Specification > > > > > > Tom-PT Taylor writes: > > > I'm willing to follow this thought along a bit further. I > > think the > > > concrete difference between the viewpoint I've documented and the > > > "policy-capability" viewpoint is this: if the MGC sends > > down a number of > > > alternative session descriptions, in my case the MG picks > > one, while in > > > Brian's case the MG replies with all the session > > descriptions it can > > > currently support. I am willing to accept the latter > > proposition if we can > > > all agree on it. From there, I will go forward with > > Chip's distinction > > > between the roles of Local and Remote, and I think we'll > > have a good > > > sensible result. > > > > Aside from the issue of not wanting to recreate > > syntax when you could use SDP to do the same, > > there are three constraints which we must adhere > > to: > > > > 1) Negotiation must happen with a three way handshake > > between the MGC and the two MG's: eg Add(o)/Add(t)/Modify(o) > > I think that Tom's original proposal does not meet this > > requirement, though Brian's does. > > > > 2) MG's which offer the set of codec alternatives in > > Brian's proposal MUST NOT be expected to have those > > coders actually loaded and prepared to process media > > packets. The MG will only prepare itself for receipt > > of packets when it sees a single choice. > > > > 3) The entire process MUST NOT lead to front end clipping. > > I'm not sure how you do this given the other constraints > > other than making it into a 4 way handshake. Maybe somebody > > more clever than me can solve that problem. > > > > > > Mike > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 07:38:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27736 for ; Tue, 4 Jan 2000 07:38:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3861DD00@standards.nortelnetworks.com>; Tue, 4 Jan 2000 7:27:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103517 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 07:26:48 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CF93140@standards.nortelnetworks.com>; Tue, 4 Jan 2000 7:26:43 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id SAA52089 for ; Tue, 4 Jan 2000 18:01:36 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3871E978.D3FB9FC5@ficon-tech.com> Date: Tue, 4 Jan 2000 18:07:13 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: Question on Transport in MEGACO To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Brian, I have a question on Transport in MEGACOP. In case of UDP Transport, when an MGC receives the first Service Change Command Request from an MG with a portId different from the default one, does the MGC send Service Change Reply on: (i) The default MG port (ii) The new PortId specified by MG (iii) The PortId from which the Service Change Command Request was sent. Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 08:05:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27989 for ; Tue, 4 Jan 2000 08:05:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFF15410@standards.nortelnetworks.com>; Tue, 4 Jan 2000 7:54:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103542 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 07:53:44 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D08CC10@standards.nortelnetworks.com>; Tue, 4 Jan 2000 7:43:43 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA17456; Tue, 4 Jan 2000 07:53:53 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA10627; Tue, 4 Jan 2000 07:53:56 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 07:51:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685C5@whq-msgusr-02.fore.com> Date: Tue, 4 Jan 2000 07:53:55 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Question on Transport in MEGACO X-To: Shalini Philip To: MEGACO@STANDARDS.NORTELNETWORKS.COM Good question. I believe the correct response would be ii) the port specified by the MG. Brian > -----Original Message----- > From: Shalini Philip [mailto:sphilip@ficon-tech.com] > Sent: Tuesday, January 04, 2000 7:37 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Question on Transport in MEGACO > > > Hello Brian, > > I have a question on Transport in MEGACOP. > > > In case of UDP Transport, when an MGC receives the first > Service Change > Command Request from an MG with a portId different from the > default one, > does the MGC send Service Change Reply on: > (i) The default MG port > (ii) The new PortId specified by MG > (iii) The PortId from which the Service Change Command > Request was sent. > > > > > Regards, > > Shalini Philip > Ficon Technology > E-Mail : mailto:sphilip@ficon-tech.com > Web : http://www.ficon-tech.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 08:39:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28274 for ; Tue, 4 Jan 2000 08:39:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2BA4CF0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 8:29:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103568 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 08:27:24 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2166D220@standards.nortelnetworks.com>; Tue, 4 Jan 2000 8:17:24 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA19159; Tue, 4 Jan 2000 08:27:37 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA14961; Tue, 4 Jan 2000 08:27:40 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 08:25:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685C6@whq-msgusr-02.fore.com> Date: Tue, 4 Jan 2000 08:27:38 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think buffering is going to be needed if you are encrypting. The real question is whether you always have to do this, or there is some way to know if you might be. The syntax problem is pretty much a "local" thing. On the originating end, you want to ask for capability. On the terminating end, you want to ask the MG to make a choice. In both cases, it's local that this happens in. The other end gets the result (the return from the add) as its remote. The following is more detail than you need, but I thought I'd write down how I think it works in great detail for others to decide if they agree, or have a different view: More specifically, the originating end gets the terminating end's local as its remote, while the terminating end gets a negotiated version of the originating end's local as its remote). Working this out a little more, the originating MGC, having no idea what the terminating side wants, has only its local policy. It puts this in local in the first Add. The originating MG filters this (takes out what it can't do), reserving worst case resources, and returns this filtered version of local in the response to the Add. There is no remote at all in this Add, because the originating MGC doesn't know any part of what goes in remote. The originating MGC sends this to the terminating MGC. The terminating MG filters the received proposal with its policy, and sends it in remote. If it will allow asymmetric coding (unusual) it could just send its policy in local, but in most cases, it will just present the same coding options it got from the originating end, filtered by it's policy (which could be reordering, as well as removing options) in local. The terminating MG gets the choices and chooses one for local and remote (usually the same, could be different) if it can and returns the single chosen value in the reply to its add. If it cannot, it means none of the offered choices are acceptable. In that case it must return an error. The response to this error might be to attempt the Add again with just the terminating end's policy, which would be returned, and then the terminating end can propose those choices in a full (non fast start) negotiation. Assuming success, the terminating MGC returns the choice to the originating MGC, which modifies the termination, both in local and remote. As with the prior discussion, this means local has what you send, and remote has what you receive (which is what the other end sends). You see the syntax issue in local? The originating MG sees an Add with an overspecified local, but returns an overspecified local. The terminating MG sees an Add with an overspecified local but returns a fully specified local. The originating MG doesn't get a remote with the add. The terminating MG sees an overspecified remote which it returns fully specified. Brian > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, January 03, 2000 6:21 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > > Rosen, Brian writes: > > If true, it means if you see media before the modify, then you > > start decoding, and if the modify says something different than > > you implied from the header, it's an error. It isn't necessary to > > wait until you get the modify before you can process the media. > > I suppose that since there is the possibility of asymmetric coding, > > you can't send any media until you have the modify. > > That's what I was afraid of. This implies that either > you load all of the proposed codecs (not just > account for their maximum MIPS and ram as you > implied), or you better be able to load the > codec PDQ once you see the first media packet. > > A worse problem is if you want to negotiate > cipher suites with payload encryption. There, > unless cipher suite negotiation is tied to the > type field somehow (it is not in packetcable, > as one data point), you have no clue how the > packet is encrypted, which effectively causes > front end clipping too. > > Since a 4-way handshake is a pretty heinous > necessity, maybe the right thing to do would be > to buffer the packets in the playback buffer > and not process them until the last Modify > came in -- this gives the whole playback > delay for the arrival of the Modify before you > had to drop the packets on the head of the > queue. > > > HOWEVER, this means we need syntax to differentiate between an > > add with policy, respond with capability, and add with policy, > > choose one and respond with your choice. > > Isn't this where Local and Remote come into > play? If I see several choices in Remote (eg > the other side's local), isn't that the trigger > for me to choose one? Or am I all screwed up here? > > Mike > > > > Brian > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Monday, January 03, 2000 1:47 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > Tom-PT Taylor writes: > > > > I'm willing to follow this thought along a bit further. I > > > think the > > > > concrete difference between the viewpoint I've > documented and the > > > > "policy-capability" viewpoint is this: if the MGC sends > > > down a number of > > > > alternative session descriptions, in my case the MG picks > > > one, while in > > > > Brian's case the MG replies with all the session > > > descriptions it can > > > > currently support. I am willing to accept the latter > > > proposition if we can > > > > all agree on it. From there, I will go forward with > > > Chip's distinction > > > > between the roles of Local and Remote, and I think we'll > > > have a good > > > > sensible result. > > > > > > Aside from the issue of not wanting to recreate > > > syntax when you could use SDP to do the same, > > > there are three constraints which we must adhere > > > to: > > > > > > 1) Negotiation must happen with a three way handshake > > > between the MGC and the two MG's: eg > Add(o)/Add(t)/Modify(o) > > > I think that Tom's original proposal does not meet this > > > requirement, though Brian's does. > > > > > > 2) MG's which offer the set of codec alternatives in > > > Brian's proposal MUST NOT be expected to have those > > > coders actually loaded and prepared to process media > > > packets. The MG will only prepare itself for receipt > > > of packets when it sees a single choice. > > > > > > 3) The entire process MUST NOT lead to front end clipping. > > > I'm not sure how you do this given the other constraints > > > other than making it into a 4 way handshake. Maybe somebody > > > more clever than me can solve that problem. > > > > > > > > > Mike > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 09:10:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28552 for ; Tue, 4 Jan 2000 09:10:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1AE74000@standards.nortelnetworks.com>; Tue, 4 Jan 2000 9:00:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103618 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 08:58:40 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E4C3FF40@standards.nortelnetworks.com>; Tue, 4 Jan 2000 8:58:39 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 4 Jan 2000 08:08:30 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 4 Jan 2000 09:08:10 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 09:08:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF56BD.20C343FE" Message-ID: Date: Tue, 4 Jan 2000 09:08:07 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF56BD.20C343FE Content-Type: text/plain; charset="iso-8859-1" I can accept this description of the process. To recap a key point: an MG knows it has to select a single alternative when it receives a non-empty Remote. Otherwise it returns Local minus whatever it couldn't allocate resources for. Now some syntactic nits: (1) Can the MG return more detail than the MGC provided? I'm thinking particularly of video, with its many parameters, but I suppose it could also happen with audio. (2) Does each new setting of Local completely replace whatever was set on that termination for that stream previously, or can some parameters be set in advance and respecified only as required? I would suggest complete replacement, because we are otherwise led further into the murky depths of SDP syntax enhancement. (3) What is the meaning of an empty descriptor when sent from the MGC to the MG? when sent from the MG to the MGC? (4) We have already (per the opening paragraph of this note) ascribed meaning to a missing Remote Descriptor in a command from the MGC to the MG. In what other cases may a Local or Remote descriptor be absent? (5) Do we accept the distinction between simultaneous resource commitments (be prepared to accept/apply any of these at any time) vs. mutually exclusive commitments (reserve resources to handle any one of these possibilities, but in the end we'll commit to just one)? Do we accept that simultaneous commitments are described within a single media session description, while mutually exclusive commitments are described in separate session descriptions? > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: Tuesday, January 04, 2000 8:28 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > I think buffering is going to be needed if you are encrypting. > The real question is whether you always have to do this, or there > is some way to know if you might be. > > The syntax problem is pretty much a "local" thing. On the originating > end, > you want to ask for capability. On the terminating end, you want to ask > the > MG to make a choice. In both cases, it's local that this happens in. The > other end gets the result (the return from the add) as its remote. > > The following is more detail than you need, but I thought I'd > write down how I think it works in great detail for others > to decide if they agree, or have a different view: > > More specifically, the originating end gets the terminating > end's local as its remote, while the terminating end gets a > negotiated version of the originating end's local as its remote). > Working this out a little more, the originating MGC, having no idea what > the > terminating side wants, has only its local policy. It puts this in local > in > the first Add. The originating MG filters this (takes out what it can't > do), reserving worst case resources, and > returns this filtered version of local in the response to the Add. > There is no remote at all in this Add, because the originating MGC > doesn't know any part of what goes in remote. > > The originating MGC sends this to the terminating MGC. The terminating MG > filters the received proposal with its policy, > and sends it in remote. If it will allow asymmetric coding (unusual) > it could just send its policy in local, but in most cases, it will > just present the same coding options it got from the originating > end, filtered by it's policy (which could be reordering, as well > as removing options) in local. > > The terminating MG gets the choices and chooses one for local and > remote (usually the same, could be different) if it can and returns > the single chosen value in the reply to its add. If it cannot, > it means none of the offered choices are acceptable. In that case > it must return an error. The response to this error might be > to attempt the Add again with just the terminating end's policy, > which would be returned, and then the terminating end can propose > those choices in a full (non fast start) negotiation. > Assuming success, the terminating MGC returns the choice to the > originating > MGC, which modifies the termination, both in local and > remote. > > As with the prior discussion, this means local has what you send, > and remote has what you receive (which is what the other end sends). > > You see the syntax issue in local? The originating MG sees an > Add with an overspecified local, but returns an overspecified local. > The terminating MG sees an Add with an overspecified local but > returns a fully specified local. The originating MG doesn't get > a remote with the add. The terminating MG sees an overspecified remote > which it returns fully specified. > > Brian > > ------_=_NextPart_001_01BF56BD.20C343FE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

I can accept this = description of the process.  To recap a key point: an MG knows it = has to select a single alternative when it receives a non-empty = Remote.  Otherwise it returns Local minus whatever it couldn't = allocate resources for.

Now some syntactic = nits:

(1) Can the MG = return more detail than the MGC provided?  I'm thinking = particularly of video, with its many parameters, but I suppose it could = also happen with audio.

(2) Does each new = setting of Local completely replace whatever was set on that = termination for that stream previously, or can some parameters be set = in advance and respecified only as required?  I would suggest = complete replacement, because we are otherwise led further into the = murky depths of SDP syntax enhancement.

(3) What is the = meaning of an empty descriptor when sent from the MGC to the MG?  = when sent from the MG to the MGC?

(4) We have already = (per the opening paragraph of this note) ascribed meaning to a missing = Remote Descriptor in a command from the MGC to the MG.  In what = other cases may a Local or Remote descriptor be absent?

(5) Do we accept the = distinction between simultaneous resource commitments (be prepared to = accept/apply any of these at any time) vs. mutually exclusive = commitments (reserve resources to handle any one of these = possibilities, but in the end we'll commit to just one)?  Do we = accept that simultaneous commitments are described within a single = media session description, while mutually exclusive commitments are = described in separate session descriptions?

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   Tuesday, January 04, 2000 8:28 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Proposed Text For Media = Specification

    I think buffering is going to be = needed if you are encrypting.
    The real question is whether you = always have to do this, or there
    is some way to know if you might = be.

    The syntax problem is pretty much a = "local" thing.  On the originating end,
    you want to ask for capability.  = On the terminating end, you want to ask the
    MG to make a choice.  In both = cases, it's local that this happens in.  The
    other end gets the result (the return = from the add) as its remote.

    The following is more detail than you = need, but I thought I'd
    write down how I think it works in = great detail for others
    to decide if they agree, or have a = different view:

    More specifically, the originating end = gets the terminating
    end's local as its remote, while the = terminating end gets a
    negotiated version of the originating = end's local as its remote).
    Working this out a little more, the = originating MGC, having no idea what the
    terminating side wants, has only its = local policy. It puts this in local in
    the first Add.  The originating = MG filters this (takes out what it can't
    do), reserving worst case resources, = and
    returns this filtered version of = local in the response to the Add.
    There is no remote at all in this = Add, because the originating MGC
    doesn't know any part of what goes in = remote.

    The originating MGC sends this to the = terminating MGC.  The terminating MG
    filters the received proposal with = its policy,
    and sends it in remote.  If it = will allow asymmetric coding (unusual)
    it could just send its policy in = local, but in most cases, it will
    just present the same coding options = it got from the originating
    end, filtered by it's policy (which = could be reordering, as well
    as removing options) in local.

    The terminating MG gets the choices = and chooses one for local and
    remote (usually the same, could be = different) if it can and returns
    the single chosen value in the reply = to its add.  If it cannot,
    it means none of the offered choices = are acceptable.  In that case
    it must return an error.  The = response to this error might be
    to attempt the Add again with just = the terminating end's policy,
    which would be returned, and then the = terminating end can propose
    those choices in a full (non fast = start) negotiation.
    Assuming success, the terminating MGC = returns the choice to the originating
    MGC, which modifies the termination, = both in local and
    remote.

    As with the prior discussion, this = means local has what you send,
    and remote has what you receive = (which is what the other end sends).

    You see the syntax issue in = local?  The originating MG sees an
    Add with an overspecified local, but = returns an overspecified local.
    The terminating MG sees an Add with = an overspecified local but
    returns a fully specified = local.  The originating MG doesn't get
    a remote with the add.  The = terminating MG sees an overspecified remote
    which it returns fully = specified.

    Brian


------_=_NextPart_001_01BF56BD.20C343FE-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 10:23:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00072 for ; Tue, 4 Jan 2000 10:23:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.333B1460@standards.nortelnetworks.com>; Tue, 4 Jan 2000 10:12:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103731 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 10:10:32 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.898377B0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 10:00:32 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA27955; Tue, 4 Jan 2000 10:10:46 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA16960; Tue, 4 Jan 2000 10:10:43 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 10:08:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF56C5.86E5A52A" Message-ID: <4FBEA8857476D311A03300204840E1CF0685CA@whq-msgusr-02.fore.com> Date: Tue, 4 Jan 2000 10:10:41 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF56C5.86E5A52A Content-Type: text/plain; charset="iso-8859-1" I can accept this description of the process. To recap a key point: an MG knows it has to select a single alternative when it receives a non-empty Remote. Otherwise it returns Local minus whatever it couldn't allocate resources for. [BR] Hmmmm, not a really wonderful way to differentiate, but it works and I have no better idea Now some syntactic nits: (1) Can the MG return more detail than the MGC provided? I'm thinking particularly of video, with its many parameters, but I suppose it could also happen with audio. [BR] I think the MG has to return a complete SDP description, whatever the MGC said, so I would say yes. I think this also improves interoperability, as an MGC doesn't have to know all about various parameters. Remember the discussion of negotiation where the MGCs weren't aware of what they were negotiating, but were able to decide anyway? (2) Does each new setting of Local completely replace whatever was set on that termination for that stream previously, or can some parameters be set in advance and respecified only as required? I would suggest complete replacement, because we are otherwise led further into the murky depths of SDP syntax enhancement. [BR] I agree, complete replacement (3) What is the meaning of an empty descriptor when sent from the MGC to the MG? when sent from the MG to the MGC? [BR] First of all, there is a big difference between empty and not mentioned. I think empty from MGC to MG is "I have no policy, tell me all you can do". I think empty from MG to MGC is an error. (4) We have already (per the opening paragraph of this note) ascribed meaning to a missing Remote Descriptor in a command from the MGC to the MG. In what other cases may a Local or Remote descriptor be absent? [BR] A simple modify could omit local/remote with impunity. An Add on the originating side without a local should be legal, but you might get an error when you modify to something real if the MG can't do it. Similarly, it ought to be okay on the terminating side. I think if you specify a local, and not a remote, you get the behavior we were discussing. Remote without local strikes me as an error. (5) Do we accept the distinction between simultaneous resource commitments (be prepared to accept/apply any of these at any time) vs. mutually exclusive commitments (reserve resources to handle any one of these possibilities, but in the end we'll commit to just one)? Do we accept that simultaneous commitments are described within a single media session description, while mutually exclusive commitments are described in separate session descriptions? [BR] I'm confused. I don't understand the distinction, and I don't understand the syntax differences. To me, the overspecified local with no remote is "be prepared to accept/apply any of these resources, reserving whatever resources you might need to do so". In the end, you ALWAYS commit to just one. -----Original Message----- From: Rosen, Brian [SMTP:brosen@FORE.COM] Sent: Tuesday, January 04, 2000 8:28 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Proposed Text For Media Specification I think buffering is going to be needed if you are encrypting. The real question is whether you always have to do this, or there is some way to know if you might be. The syntax problem is pretty much a "local" thing. On the originating end, you want to ask for capability. On the terminating end, you want to ask the MG to make a choice. In both cases, it's local that this happens in. The other end gets the result (the return from the add) as its remote. The following is more detail than you need, but I thought I'd write down how I think it works in great detail for others to decide if they agree, or have a different view: More specifically, the originating end gets the terminating end's local as its remote, while the terminating end gets a negotiated version of the originating end's local as its remote). Working this out a little more, the originating MGC, having no idea what the terminating side wants, has only its local policy. It puts this in local in the first Add. The originating MG filters this (takes out what it can't do), reserving worst case resources, and returns this filtered version of local in the response to the Add. There is no remote at all in this Add, because the originating MGC doesn't know any part of what goes in remote. The originating MGC sends this to the terminating MGC. The terminating MG filters the received proposal with its policy, and sends it in remote. If it will allow asymmetric coding (unusual) it could just send its policy in local, but in most cases, it will just present the same coding options it got from the originating end, filtered by it's policy (which could be reordering, as well as removing options) in local. The terminating MG gets the choices and chooses one for local and remote (usually the same, could be different) if it can and returns the single chosen value in the reply to its add. If it cannot, it means none of the offered choices are acceptable. In that case it must return an error. The response to this error might be to attempt the Add again with just the terminating end's policy, which would be returned, and then the terminating end can propose those choices in a full (non fast start) negotiation. Assuming success, the terminating MGC returns the choice to the originating MGC, which modifies the termination, both in local and remote. As with the prior discussion, this means local has what you send, and remote has what you receive (which is what the other end sends). You see the syntax issue in local? The originating MG sees an Add with an overspecified local, but returns an overspecified local. The terminating MG sees an Add with an overspecified local but returns a fully specified local. The originating MG doesn't get a remote with the add. The terminating MG sees an overspecified remote which it returns fully specified. Brian ------_=_NextPart_001_01BF56C5.86E5A52A Content-Type: text/html; charset="iso-8859-1" RE: Proposed Text For Media Specification

I can accept this description of the process.  To recap a key point: an MG knows it has to select a single alternative when it receives a non-empty Remote.  Otherwise it returns Local minus whatever it couldn't allocate resources for. 

[BR] Hmmmm, not a really wonderful way to differentiate, but it works and I have no better idea 

Now some syntactic nits:

(1) Can the MG return more detail than the MGC provided?  I'm thinking particularly of video, with its many parameters, but I suppose it could also happen with audio. 

[BR] I think the MG has to return a complete SDP description, whatever the MGC said, so I would say yes.  I think this also improves interoperability, as an MGC doesn't have to know all about various parameters.  Remember the discussion of negotiation where the MGCs weren't aware of what they were negotiating, but were able to decide anyway? 

(2) Does each new setting of Local completely replace whatever was set on that termination for that stream previously, or can some parameters be set in advance and respecified only as required?  I would suggest complete replacement, because we are otherwise led further into the murky depths of SDP syntax enhancement. 

[BR] I agree, complete replacement 

(3) What is the meaning of an empty descriptor when sent from the MGC to the MG?  when sent from the MG to the MGC?  

[BR] First of all, there is a big difference between empty and not mentioned.  I think empty from MGC to MG is "I have no policy, tell me all you can do".  I think empty from MG to MGC is an error. 

(4) We have already (per the opening paragraph of this note) ascribed meaning to a missing Remote Descriptor in a command from the MGC to the MG.  In what other cases may a Local or Remote descriptor be absent? 

[BR] A simple modify could omit local/remote with impunity.  An Add on the originating side without a local should be legal, but you might get an error when you modify to something real if the MG can't do it.  Similarly, it ought to be okay on the terminating side.  I think if you specify a local, and not a remote, you get the behavior we were discussing.  Remote without local strikes me as an error. 

(5) Do we accept the distinction between simultaneous resource commitments (be prepared to accept/apply any of these at any time) vs. mutually exclusive commitments (reserve resources to handle any one of these possibilities, but in the end we'll commit to just one)?  Do we accept that simultaneous commitments are described within a single media session description, while mutually exclusive commitments are described in separate session descriptions? 

[BR] I'm confused.  I don't understand the distinction, and I don't understand the syntax differences.  To me, the overspecified local with no remote is "be prepared to accept/apply any of these resources, reserving whatever resources you might need to do so".  In the end, you ALWAYS commit to just one. 

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   Tuesday, January 04, 2000 8:28 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: Proposed Text For Media Specification

    I think buffering is going to be needed if you are encrypting.
    The real question is whether you always have to do this, or there
    is some way to know if you might be.

    The syntax problem is pretty much a "local" thing.  On the originating end,
    you want to ask for capability.  On the terminating end, you want to ask the
    MG to make a choice.  In both cases, it's local that this happens in.  The
    other end gets the result (the return from the add) as its remote.

    The following is more detail than you need, but I thought I'd
    write down how I think it works in great detail for others
    to decide if they agree, or have a different view:

    More specifically, the originating end gets the terminating
    end's local as its remote, while the terminating end gets a
    negotiated version of the originating end's local as its remote).
    Working this out a little more, the originating MGC, having no idea what the
    terminating side wants, has only its local policy. It puts this in local in
    the first Add.  The originating MG filters this (takes out what it can't
    do), reserving worst case resources, and
    returns this filtered version of local in the response to the Add.
    There is no remote at all in this Add, because the originating MGC
    doesn't know any part of what goes in remote.

    The originating MGC sends this to the terminating MGC.  The terminating MG
    filters the received proposal with its policy,
    and sends it in remote.  If it will allow asymmetric coding (unusual)
    it could just send its policy in local, but in most cases, it will
    just present the same coding options it got from the originating
    end, filtered by it's policy (which could be reordering, as well
    as removing options) in local.

    The terminating MG gets the choices and chooses one for local and
    remote (usually the same, could be different) if it can and returns
    the single chosen value in the reply to its add.  If it cannot,
    it means none of the offered choices are acceptable.  In that case
    it must return an error.  The response to this error might be
    to attempt the Add again with just the terminating end's policy,
    which would be returned, and then the terminating end can propose
    those choices in a full (non fast start) negotiation.
    Assuming success, the terminating MGC returns the choice to the originating
    MGC, which modifies the termination, both in local and
    remote.

    As with the prior discussion, this means local has what you send,
    and remote has what you receive (which is what the other end sends).

    You see the syntax issue in local?  The originating MG sees an
    Add with an overspecified local, but returns an overspecified local.
    The terminating MG sees an Add with an overspecified local but
    returns a fully specified local.  The originating MG doesn't get
    a remote with the add.  The terminating MG sees an overspecified remote
    which it returns fully specified.

    Brian


------_=_NextPart_001_01BF56C5.86E5A52A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 11:03:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01304 for ; Tue, 4 Jan 2000 11:03:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CD518B60@standards.nortelnetworks.com>; Tue, 4 Jan 2000 10:52:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103795 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 10:51:12 -0500 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9DC17D10@standards.nortelnetworks.com>; Tue, 4 Jan 2000 10:51:12 -0500 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA12203 for ; Tue, 4 Jan 2000 11:01:28 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA12181 for ; Tue, 4 Jan 2000 11:01:28 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA08494; Tue, 4 Jan 2000 17:01:24 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA08486; Tue, 4 Jan 2000 17:01:23 +0100 (MET) X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF0685CA@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38721909.2083EB74@lucent.com> Date: Tue, 4 Jan 2000 17:00:09 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Proposed Text For Media Specification To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This is going in the right direction. I've got a couple of comments and a question. (3) (for clarification) If a MGC supplies one fully specified (local) descriptor, the MG's reply will not contain that descriptor (as opposed to an empty descriptor being sent from MG to MGC). (4) Remote without local may occur in case a one way stream is being set up. The MG doesn't have to be prepared to receive anything, it will only send media. (5) I don't quite understand Tom's question either. Earlier in the thread there was discussion about which descriptor to use in the first Add on the originating side. Is Local used, or LocalControl? I don't think it was resolved. In my opinion it has to be Local. John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 11:20:24 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01674 for ; Tue, 4 Jan 2000 11:20:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F2D33A0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 11:09:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103820 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 11:07:59 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FE651B0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 10:57:58 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA03651; Tue, 4 Jan 2000 11:08:13 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA03813; Tue, 4 Jan 2000 11:08:15 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 11:05:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF0685CF@whq-msgusr-02.fore.com> Date: Tue, 4 Jan 2000 11:08:11 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM > (3) (for clarification) If a MGC supplies one fully specified (local) > descriptor, the MG's reply will not contain that descriptor > (as opposed > to an empty descriptor being sent from MG to MGC). Right. No reason to, and it fits the current behavior (no response to fully specified descriptors) > (4) Remote without local may occur in case a one way stream > is being set > up. The MG doesn't have to be prepared to receive anything, it will > only send media. Okay, good point. So it's legal, not an error. > (5) I don't quite understand Tom's question either. > > Earlier in the thread there was discussion about which > descriptor to use > in the first Add on the originating side. Is Local used, or > LocalControl? I don't think it was resolved. In my opinion it has to > be Local. There were people who believed you "had" to specify network type in localControl. I never understood why; SDP and Annex D fully describe network type. Other than that, I think we all agree, it's local, not localControl. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 11:58:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02276 for ; Tue, 4 Jan 2000 11:58:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8008B7E0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 11:47:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103859 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 11:47:06 -0500 Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CD95F30@standards.nortelnetworks.com>; Tue, 4 Jan 2000 11:47:06 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA28152; Tue, 4 Jan 2000 08:51:15 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA19885; Tue, 4 Jan 2000 08:57:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF0685C6@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14450.9835.907394.966823@thomasm-u1.cisco.com> Date: Tue, 4 Jan 2000 08:57:15 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF0685C6@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Detail at this point is a Good Thing. I had always thought that one of the motivations for Remote was to enable asynchronous negotiation; remember that MGCP only passes one SDP back and forth. Here's a scenario, however, that I think satisfies all of the conditions though: 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} MGC sends initial add to the originator; remote unknown. Local choice are policy 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} MGo chooses s1 and s3; can't do s2 because of resources 3) MGC->MGt: Add { Local { s1, s2, s3} Remote { s1, s3}} MGC adds MGt, sets policy in local, sends choices in remote from MGo 4) 1) MGt->MGC: Add = { Local { s1 } Remote { s1}} MGt firstly notices that Remote has choices. It then SHOULD take the intersection of Local and Remote's choices and return the most preferable choice (ie, first in list). If there is not an intersection, MG MUST choose one in Remote and send back the choices in Local that it can accommodate 5) MGC->MGo: Modify { Local { s1 } Remote { s1 }} MGC modifies MGo with the choices, which are fully qualified at this point. 6) 1) MGo->MGC: Modify = { Local { s1 } Remote { s1}} MGo acks the Modify For *asynchronous* negotiation we modify the flow slightly: 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} MGC sends initial add to the originator; remote unknown. Local choice are policy 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} MGo chooses s1 and s3; can't do s2 because of resources 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} MGC adds MGt, sets policy in local, sends choices in remote from MGo; note MGC sends policy of not using s1 (for whatever reason) 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} MGt firstly notices that Remote has choices. It then SHOULD take the intersection of Local and Remote's choices and return the most preferable choice (ie, first in list). If there is not an intersection, MG MUST choose one in Remote and send back the choices in Local that it can accommodate (s2, s3). 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} MGC modifies MGo with the choices. Note Remote is not fully qualified. The MGC MUST at this point remember that it needs to do a 4 way handshake since it saw choices in remote going to MGo 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} MGo acks the Modify, and chooses s3 because it still cannot do s2 in remote 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} MGC transmits the final choices to MGt 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} MGt acks the modify and we're going. Mike Rosen, Brian writes: > I think buffering is going to be needed if you are encrypting. > The real question is whether you always have to do this, or there > is some way to know if you might be. > > The syntax problem is pretty much a "local" thing. On the originating end, > you want to ask for capability. On the terminating end, you want to ask the > MG to make a choice. In both cases, it's local that this happens in. The > other end gets the result (the return from the add) as its remote. > > The following is more detail than you need, but I thought I'd > write down how I think it works in great detail for others > to decide if they agree, or have a different view: > > More specifically, the originating end gets the terminating > end's local as its remote, while the terminating end gets a > negotiated version of the originating end's local as its remote). > Working this out a little more, the originating MGC, having no idea what the > terminating side wants, has only its local policy. It puts this in local in > the first Add. The originating MG filters this (takes out what it can't > do), reserving worst case resources, and > returns this filtered version of local in the response to the Add. > There is no remote at all in this Add, because the originating MGC > doesn't know any part of what goes in remote. > > The originating MGC sends this to the terminating MGC. The terminating MG > filters the received proposal with its policy, > and sends it in remote. If it will allow asymmetric coding (unusual) > it could just send its policy in local, but in most cases, it will > just present the same coding options it got from the originating > end, filtered by it's policy (which could be reordering, as well > as removing options) in local. > > The terminating MG gets the choices and chooses one for local and > remote (usually the same, could be different) if it can and returns > the single chosen value in the reply to its add. If it cannot, > it means none of the offered choices are acceptable. In that case > it must return an error. The response to this error might be > to attempt the Add again with just the terminating end's policy, > which would be returned, and then the terminating end can propose > those choices in a full (non fast start) negotiation. > Assuming success, the terminating MGC returns the choice to the originating > MGC, which modifies the termination, both in local and > remote. > > As with the prior discussion, this means local has what you send, > and remote has what you receive (which is what the other end sends). > > You see the syntax issue in local? The originating MG sees an > Add with an overspecified local, but returns an overspecified local. > The terminating MG sees an Add with an overspecified local but > returns a fully specified local. The originating MG doesn't get > a remote with the add. The terminating MG sees an overspecified remote > which it returns fully specified. > > Brian > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Monday, January 03, 2000 6:21 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Proposed Text For Media Specification > > > > > > Rosen, Brian writes: > > > If true, it means if you see media before the modify, then you > > > start decoding, and if the modify says something different than > > > you implied from the header, it's an error. It isn't necessary to > > > wait until you get the modify before you can process the media. > > > I suppose that since there is the possibility of asymmetric coding, > > > you can't send any media until you have the modify. > > > > That's what I was afraid of. This implies that either > > you load all of the proposed codecs (not just > > account for their maximum MIPS and ram as you > > implied), or you better be able to load the > > codec PDQ once you see the first media packet. > > > > A worse problem is if you want to negotiate > > cipher suites with payload encryption. There, > > unless cipher suite negotiation is tied to the > > type field somehow (it is not in packetcable, > > as one data point), you have no clue how the > > packet is encrypted, which effectively causes > > front end clipping too. > > > > Since a 4-way handshake is a pretty heinous > > necessity, maybe the right thing to do would be > > to buffer the packets in the playback buffer > > and not process them until the last Modify > > came in -- this gives the whole playback > > delay for the arrival of the Modify before you > > had to drop the packets on the head of the > > queue. > > > > > HOWEVER, this means we need syntax to differentiate between an > > > add with policy, respond with capability, and add with policy, > > > choose one and respond with your choice. > > > > Isn't this where Local and Remote come into > > play? If I see several choices in Remote (eg > > the other side's local), isn't that the trigger > > for me to choose one? Or am I all screwed up here? > > > > Mike > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > I'm willing to follow this thought along a bit further. I > > > > think the > > > > > concrete difference between the viewpoint I've > > documented and the > > > > > "policy-capability" viewpoint is this: if the MGC sends > > > > down a number of > > > > > alternative session descriptions, in my case the MG picks > > > > one, while in > > > > > Brian's case the MG replies with all the session > > > > descriptions it can > > > > > currently support. I am willing to accept the latter > > > > proposition if we can > > > > > all agree on it. From there, I will go forward with > > > > Chip's distinction > > > > > between the roles of Local and Remote, and I think we'll > > > > have a good > > > > > sensible result. > > > > > > > > Aside from the issue of not wanting to recreate > > > > syntax when you could use SDP to do the same, > > > > there are three constraints which we must adhere > > > > to: > > > > > > > > 1) Negotiation must happen with a three way handshake > > > > between the MGC and the two MG's: eg > > Add(o)/Add(t)/Modify(o) > > > > I think that Tom's original proposal does not meet this > > > > requirement, though Brian's does. > > > > > > > > 2) MG's which offer the set of codec alternatives in > > > > Brian's proposal MUST NOT be expected to have those > > > > coders actually loaded and prepared to process media > > > > packets. The MG will only prepare itself for receipt > > > > of packets when it sees a single choice. > > > > > > > > 3) The entire process MUST NOT lead to front end clipping. > > > > I'm not sure how you do this given the other constraints > > > > other than making it into a 4 way handshake. Maybe somebody > > > > more clever than me can solve that problem. > > > > > > > > > > > > Mike > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 12:33:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02975 for ; Tue, 4 Jan 2000 12:33:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B8922C0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:21:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104040 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 12:20:33 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18FE4B00@standards.nortelnetworks.com>; Tue, 4 Jan 2000 12:20:33 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 4 Jan 2000 11:30:04 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 4 Jan 2000 12:29:34 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 11:29:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF56D9.4250866E" Message-ID: Date: Tue, 4 Jan 2000 11:29:25 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-To: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF56D9.4250866E Content-Type: text/plain; charset="ISO-8859-1" In your second case in step (4), why doesn't the MG converge on the single selection s3 for Local and Remote? How does it know that it should leave Local unresolved? > -----Original Message----- > From: Michael Thomas [SMTP:mat@CISCO.COM] > Sent: Tuesday, January 04, 2000 11:57 AM [[TomT]] First case snipped. > For *asynchronous* negotiation we modify the flow > slightly: > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > MGC sends initial add to the originator; remote > unknown. Local choice are policy > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > MGo chooses s1 and s3; can't do s2 because of > resources > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > MGC adds MGt, sets policy in local, sends > choices in remote from MGo; note MGC sends > policy of not using s1 (for whatever reason) > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > MGt firstly notices that Remote has choices. It > then SHOULD take the intersection of Local and > Remote's choices and return the most preferable > choice (ie, first in list). If there is not an > intersection, MG MUST choose one in Remote and > send back the choices in Local that it can > accommodate (s2, s3). > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > MGC modifies MGo with the choices. Note Remote > is not fully qualified. The MGC MUST at this > point remember that it needs to do a 4 way > handshake since it saw choices in remote going > to MGo > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > MGo acks the Modify, and chooses s3 because it > still cannot do s2 in remote > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > MGC transmits the final choices to MGt > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > MGt acks the modify and we're going. > > Mike > > Rosen, Brian writes: > > I think buffering is going to be needed if you are encrypting. > > The real question is whether you always have to do this, or there > > is some way to know if you might be. > > > > The syntax problem is pretty much a "local" thing. On the originating > end, > > you want to ask for capability. On the terminating end, you want to > ask the > > MG to make a choice. In both cases, it's local that this happens in. > The > > other end gets the result (the return from the add) as its remote. > > > > The following is more detail than you need, but I thought I'd > > write down how I think it works in great detail for others > > to decide if they agree, or have a different view: > > > > More specifically, the originating end gets the terminating > > end's local as its remote, while the terminating end gets a > > negotiated version of the originating end's local as its remote). > > Working this out a little more, the originating MGC, having no idea > what the > > terminating side wants, has only its local policy. It puts this in > local in > > the first Add. The originating MG filters this (takes out what it > can't > > do), reserving worst case resources, and > > returns this filtered version of local in the response to the Add. > > There is no remote at all in this Add, because the originating MGC > > doesn't know any part of what goes in remote. > > > > The originating MGC sends this to the terminating MGC. The terminating > MG > > filters the received proposal with its policy, > > and sends it in remote. If it will allow asymmetric coding (unusual) > > it could just send its policy in local, but in most cases, it will > > just present the same coding options it got from the originating > > end, filtered by it's policy (which could be reordering, as well > > as removing options) in local. > > > > The terminating MG gets the choices and chooses one for local and > > remote (usually the same, could be different) if it can and returns > > the single chosen value in the reply to its add. If it cannot, > > it means none of the offered choices are acceptable. In that case > > it must return an error. The response to this error might be > > to attempt the Add again with just the terminating end's policy, > > which would be returned, and then the terminating end can propose > > those choices in a full (non fast start) negotiation. > > Assuming success, the terminating MGC returns the choice to the > originating > > MGC, which modifies the termination, both in local and > > remote. > > > > As with the prior discussion, this means local has what you send, > > and remote has what you receive (which is what the other end sends). > > > > You see the syntax issue in local? The originating MG sees an > > Add with an overspecified local, but returns an overspecified local. > > The terminating MG sees an Add with an overspecified local but > > returns a fully specified local. The originating MG doesn't get > > a remote with the add. The terminating MG sees an overspecified remote > > which it returns fully specified. > > > > Brian > > > > > -----Original Message----- > > > From: Michael Thomas [mailto:mat@cisco.com] > > > Sent: Monday, January 03, 2000 6:21 PM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > Rosen, Brian writes: > > > > If true, it means if you see media before the modify, then you > > > > start decoding, and if the modify says something different than > > > > you implied from the header, it's an error. It isn't necessary to > > > > wait until you get the modify before you can process the media. > > > > I suppose that since there is the possibility of asymmetric > coding, > > > > you can't send any media until you have the modify. > > > > > > That's what I was afraid of. This implies that either > > > you load all of the proposed codecs (not just > > > account for their maximum MIPS and ram as you > > > implied), or you better be able to load the > > > codec PDQ once you see the first media packet. > > > > > > A worse problem is if you want to negotiate > > > cipher suites with payload encryption. There, > > > unless cipher suite negotiation is tied to the > > > type field somehow (it is not in packetcable, > > > as one data point), you have no clue how the > > > packet is encrypted, which effectively causes > > > front end clipping too. > > > > > > Since a 4-way handshake is a pretty heinous > > > necessity, maybe the right thing to do would be > > > to buffer the packets in the playback buffer > > > and not process them until the last Modify > > > came in -- this gives the whole playback > > > delay for the arrival of the Modify before you > > > had to drop the packets on the head of the > > > queue. > > > > > > > HOWEVER, this means we need syntax to differentiate between an > > > > add with policy, respond with capability, and add with policy, > > > > choose one and respond with your choice. > > > > > > Isn't this where Local and Remote come into > > > play? If I see several choices in Remote (eg > > > the other side's local), isn't that the trigger > > > for me to choose one? Or am I all screwed up here? > > > > > > Mike > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > I'm willing to follow this thought along a bit further. I > > > > > think the > > > > > > concrete difference between the viewpoint I've > > > documented and the > > > > > > "policy-capability" viewpoint is this: if the MGC sends > > > > > down a number of > > > > > > alternative session descriptions, in my case the MG picks > > > > > one, while in > > > > > > Brian's case the MG replies with all the session > > > > > descriptions it can > > > > > > currently support. I am willing to accept the latter > > > > > proposition if we can > > > > > > all agree on it. From there, I will go forward with > > > > > Chip's distinction > > > > > > between the roles of Local and Remote, and I think we'll > > > > > have a good > > > > > > sensible result. > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > syntax when you could use SDP to do the same, > > > > > there are three constraints which we must adhere > > > > > to: > > > > > > > > > > 1) Negotiation must happen with a three way handshake > > > > > between the MGC and the two MG's: eg > > > Add(o)/Add(t)/Modify(o) > > > > > I think that Tom's original proposal does not meet this > > > > > requirement, though Brian's does. > > > > > > > > > > 2) MG's which offer the set of codec alternatives in > > > > > Brian's proposal MUST NOT be expected to have those > > > > > coders actually loaded and prepared to process media > > > > > packets. The MG will only prepare itself for receipt > > > > > of packets when it sees a single choice. > > > > > > > > > > 3) The entire process MUST NOT lead to front end clipping. > > > > > I'm not sure how you do this given the other constraints > > > > > other than making it into a 4 way handshake. Maybe > somebody > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01BF56D9.4250866E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

In your second case = in step (4), why doesn't the MG converge on the single selection s3 for = Local and Remote?  How does it know that it should leave Local = unresolved?

    -----Original Message-----
    From:   Michael Thomas [SMTP:mat@CISCO.COM]
    Sent:   Tuesday, January 04, 2000 11:57 AM
    [[TomT]]  First case = snipped.=20

    For *asynchronous* negotiation we = modify the flow
    slightly:


    1) MGC->MGo: Add { Local { s1, s2, = s3} Remote {}}

       MGC sends initial add to = the originator; remote
       unknown. Local choice = are policy

    2) MGo->MGC: Add =3D { Local { s1, = s3} Remote {}}

       MGo chooses s1 and s3; = can't do s2 because of
       resources

    3) MGC->MGt: Add { Local { s2, s3} = Remote { s1, s3}}

       MGC adds MGt, sets policy = in local, sends
       choices in remote from = MGo; note MGC sends
       policy of not using s1 = (for whatever reason)

    4) MGt->MGC: Add =3D { Local { s2, = s3 } Remote {s1}}

       MGt firstly notices that = Remote has choices. It
       then SHOULD take the = intersection of Local and
       Remote's choices and = return the most preferable
       choice (ie, first in = list). If there is not an
       intersection, MG MUST = choose one in Remote and
       send back the choices in = Local that it can
       accommodate (s2, = s3).

    5) MGC->MGo: Modify { Local { s1 } = Remote { s2, s3 }}

       MGC modifies MGo with the = choices. Note Remote
       is not fully qualified. = The MGC MUST at this
       point remember that it = needs to do a 4 way
       handshake since it saw = choices in remote going
       to MGo

    6) MGo->MGC: Modify =3D { Local { = s1 } Remote { s3}}

       MGo acks the Modify, and = chooses s3 because it
       still cannot do s2 in = remote

    7) MGC->MGt: Modify { Local { s3 } = Remote { s1 }}

       MGC transmits the = final  choices to MGt

    8) MGt->MGC: Modify =3D { Local { = s3 } Remote { s1}}

       MGt acks the modify and = we're going.

             &nb= sp;  Mike

    Rosen, Brian writes:
     > I think buffering is going = to be needed if you are encrypting.
     > The real question is = whether you always have to do this, or there
     > is some way to know if you = might be.
     >
     > The syntax problem is = pretty much a "local" thing.  On the originating = end,
     > you want to ask for = capability.  On the terminating end, you want to ask the
     > MG to make a choice.  = In both cases, it's local that this happens in.  The
     > other end gets the result = (the return from the add) as its remote.
     >
     > The following is more = detail than you need, but I thought I'd
     > write down how I think it = works in great detail for others
     > to decide if they agree, = or have a different view:
     >
     > More specifically, the = originating end gets the terminating
     > end's local as its remote, = while the terminating end gets a
     > negotiated version of the = originating end's local as its remote).
     > Working this out a little = more, the originating MGC, having no idea what the
     > terminating side wants, = has only its local policy. It puts this in local in
     > the first Add.  The = originating MG filters this (takes out what it can't
     > do), reserving worst case = resources, and
     > returns this filtered = version of local in the response to the Add.
     > There is no remote at all = in this Add, because the originating MGC
     > doesn't know any part of = what goes in remote.
     >
     > The originating MGC sends = this to the terminating MGC.  The terminating MG
     > filters the received = proposal with its policy,
     > and sends it in = remote.  If it will allow asymmetric coding (unusual)
     > it could just send its = policy in local, but in most cases, it will
     > just present the same = coding options it got from the originating
     > end, filtered by it's = policy (which could be reordering, as well
     > as removing options) in = local.
     >
     > The terminating MG gets = the choices and chooses one for local and
     > remote (usually the same, = could be different) if it can and returns
     > the single chosen value in = the reply to its add.  If it cannot,
     > it means none of the = offered choices are acceptable.  In that case
     > it must return an = error.  The response to this error might be
     > to attempt the Add again = with just the terminating end's policy,
     > which would be returned, = and then the terminating end can propose
     > those choices in a full = (non fast start) negotiation.
     > Assuming success, the = terminating MGC returns the choice to the originating
     > MGC, which modifies the = termination, both in local and
     > remote.
     >
     > As with the prior = discussion, this means local has what you send,
     > and remote has what you = receive (which is what the other end sends).
     >
     > You see the syntax issue = in local?  The originating MG sees an
     > Add with an overspecified = local, but returns an overspecified local.
     > The terminating MG sees an = Add with an overspecified local but
     > returns a fully specified = local.  The originating MG doesn't get
     > a remote with the = add.  The terminating MG sees an overspecified remote
     > which it returns fully = specified.
     >
     > Brian
     >
     > > -----Original = Message-----
     > > From: Michael Thomas = [mailto:mat@cisco.com]
     > > Sent: Monday, January = 03, 2000 6:21 PM
     > > To: Rosen, = Brian
     > > Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM
     > > Subject: Re: Proposed = Text For Media Specification
     > >
     > >
     > > Rosen, Brian = writes:
     > >  > If true, = it means if you see media before the modify, then you
     > >  > start = decoding, and if the modify says something different than
     > >  > you = implied from the header, it's an error.  It isn't necessary = to
     > >  > wait until = you get the modify before you can process the media.
     > >  > I suppose = that since there is the possibility of asymmetric coding,
     > >  > you can't = send any media until you have the modify.
     > >
     > >    = That's what I was afraid of. This implies that either
     > >    you = load all of the proposed codecs (not just
     > >    = account for their maximum MIPS and ram as you
     > >    = implied), or you  better be able to load the
     > >    = codec PDQ once you see the first media packet.
     > >
     > >    A = worse problem is if you want to negotiate
     > >    = cipher suites with payload encryption. There,
     > >    = unless cipher suite negotiation is tied to the
     > >    = type field somehow (it is not in packetcable,
     > >    as = one data point), you have no clue how the
     > >    = packet is encrypted, which effectively causes
     > >    = front end clipping too.
     > >
     > >    = Since a 4-way handshake is a pretty heinous
     > >    = necessity, maybe the right thing to do would be
     > >    to = buffer the packets in the playback buffer
     > >    and = not process them until the last Modify
     > >    = came in -- this gives the whole playback
     > >    = delay for the arrival of the Modify before you
     > >    had = to drop the packets on the head of the
     > >    = queue.
     > >
     > >  > HOWEVER, = this means we need syntax to differentiate between an
     > >  > add with = policy, respond with capability, and add with policy,
     > >  > choose one = and respond with your choice.
     > >
     > >    = Isn't this where Local and Remote come into
     > >    = play? If I see several choices in Remote (eg
     > >    the = other side's local), isn't that the trigger
     > >    for = me to choose one? Or am I all screwed up here?
     > >
     > = >            = Mike
     > >  >
     > >  > = Brian
     > >  >
     > >  > > = -----Original Message-----
     > >  > > From: = Michael Thomas [mailto:mat@cisco.com]
     > >  > > Sent: = Monday, January 03, 2000 1:47 PM
     > >  > > To: = MEGACO@standards.nortelnetworks.com
     > >  > > = Subject: Re: Proposed Text For Media Specification
     > >  > = >
     > >  > = >
     > >  > > = Tom-PT Taylor writes:
     > >  > >  = > I'm willing to follow this thought along a bit further.  = I
     > >  > > think = the
     > >  > >  = > concrete difference between the viewpoint I've
     > > documented and = the
     > >  > >  = > "policy-capability" viewpoint is this: if the MGC = sends
     > >  > > down = a number of
     > >  > >  = > alternative session descriptions, in my case the MG picks
     > >  > > one, = while in
     > >  > >  = > Brian's case the MG replies with all the session
     > >  > > = descriptions it can
     > >  > >  = > currently support.  I am willing to accept the latter
     > >  > > = proposition if we can
     > >  > >  = > all agree on it.  From there, I will go forward with
     > >  > > = Chip's distinction
     > >  > >  = > between the roles of Local and Remote, and I think we'll
     > >  > > have = a good
     > >  > >  = > sensible result.
     > >  > = >
     > >  > = >    Aside from the issue of not wanting to = recreate
     > >  > = >    syntax when you could use SDP to do the = same,
     > >  > = >    there are three constraints which we must = adhere
     > >  > = >    to:
     > >  > = >
     > >  > = >    1) Negotiation must happen with a three way = handshake
     > >  > = >       between the MGC and the two = MG's: eg
     > > = Add(o)/Add(t)/Modify(o)
     > >  > = >       I think that Tom's original = proposal does not meet this
     > >  > = >       requirement, though Brian's = does.
     > >  > = >
     > >  > = >    2) MG's which offer the set of codec = alternatives in
     > >  > = >       Brian's proposal MUST NOT be = expected to have those
     > >  > = >       coders actually loaded and = prepared to process media
     > >  > = >       packets. The MG will only = prepare itself for receipt
     > >  > = >       of packets when it sees a = single choice.
     > >  > = >
     > >  > = >    3) The entire process MUST NOT lead to front end = clipping.
     > >  > = >       I'm not sure how you do this = given the other constraints
     > >  > = >       other than making it into a 4 = way handshake. Maybe somebody
     > >  > = >       more clever than me can solve = that problem.
     > >  > = >
     > >  > = >
     > >  > = >           &n= bsp;       Mike
     > >  > = >
     > >  >
     > >  >
     > >
     >
     >

------_=_NextPart_001_01BF56D9.4250866E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 13:28:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03567 for ; Tue, 4 Jan 2000 13:28:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFAF96B0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 13:17:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104143 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 13:15:27 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C41BF8A0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 13:15:26 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 4 Jan 2000 12:24:52 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 4 Jan 2000 13:24:30 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 4 Jan 2000 13:24:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF56E0.EFB24426" Message-ID: Date: Tue, 4 Jan 2000 13:24:26 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF56E0.EFB24426 Content-Type: text/plain; charset="iso-8859-1" We're getting close. Just a couple of points. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 04, 2000 10:11 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > [[TomT]] agreed points snipped > (3) What is the meaning of an empty descriptor when sent from the > MGC to the MG? when sent from the MG to the MGC? > > [BR] First of all, there is a big difference between empty and not > mentioned. I think empty from MGC to MG is "I have no policy, tell me all > you can do". I think empty from MG to MGC is an error. > [[TomT]] I assume it's not just "tell me all you can do", but also "reserve resources for what you tell me about". [[TomT]] ... > > (5) Do we accept the distinction between simultaneous resource > commitments (be prepared to accept/apply any of these at any time) vs. > mutually exclusive commitments (reserve resources to handle any one of > these possibilities, but in the end we'll commit to just one)? Do we > accept that simultaneous commitments are described within a single media > session description, while mutually exclusive commitments are described in > separate session descriptions? > > [BR] I'm confused. I don't understand the distinction, and I don't > understand the syntax differences. To me, the overspecified local with no > remote is "be prepared to accept/apply any of these resources, reserving > whatever resources you might need to do so". In the end, you ALWAYS > commit to just one. > [[TomT]] You may alternate, as in simultaneous use of G.723.1 and the TONES payload. Thus you commit to two encodings and corresponding payload types rather than one. Here is the syntax as I see it: v=0 i=G.711 alternative -- the preferred one s=1 ... m=audio $ RTP/AVP 0 v=0 i=G.723.1 plus TONES encoding s=2 ... m=audio $ RTP/AVP 4 96 a=rtpmap:96 X-TONES To quote from RFC 2327 (SDP): When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session. Thus a single session description listing G.711, G.723.1, and TONES on the same line doesn't have the same meaning as what I show above. I'm proposing that the above means that the MG must reserve resources to support both session 1 and session 2 for the moment. This part is straightforward. The next part is special interpretation: that if multiple session descriptions are given for the same stream, only one will ever be used, so, for instance, the MG can assign the same port for every session description. Can we agree on this interpretation? > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: Tuesday, January 04, 2000 8:28 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > I think buffering is going to be needed if you are > encrypting. > The real question is whether you always have to do this, or there > is some way to know if you might be. > > The syntax problem is pretty much a "local" thing. On the > originating end, > you want to ask for capability. On the terminating end, you want to > ask the > MG to make a choice. In both cases, it's local that this happens > in. The > other end gets the result (the return from the add) as its remote. > > The following is more detail than you need, but I thought > I'd > write down how I think it works in great detail for others > to decide if they agree, or have a different view: > > More specifically, the originating end gets the terminating > end's local as its remote, while the terminating end gets a > negotiated version of the originating end's local as its remote). > Working this out a little more, the originating MGC, having no idea > what the > terminating side wants, has only its local policy. It puts this in > local in > the first Add. The originating MG filters this (takes out what it > can't > do), reserving worst case resources, and > returns this filtered version of local in the response to the Add. > There is no remote at all in this Add, because the originating MGC > doesn't know any part of what goes in remote. > > The originating MGC sends this to the terminating MGC. The > terminating MG > filters the received proposal with its policy, > and sends it in remote. If it will allow asymmetric coding > (unusual) > it could just send its policy in local, but in most cases, it will > just present the same coding options it got from the originating > end, filtered by it's policy (which could be reordering, as well > as removing options) in local. > > The terminating MG gets the choices and chooses one for > local and > remote (usually the same, could be different) if it can and returns > the single chosen value in the reply to its add. If it cannot, > it means none of the offered choices are acceptable. In that case > it must return an error. The response to this error might be > to attempt the Add again with just the terminating end's policy, > which would be returned, and then the terminating end can propose > those choices in a full (non fast start) negotiation. > Assuming success, the terminating MGC returns the choice to the > originating > MGC, which modifies the termination, both in local and > remote. > > As with the prior discussion, this means local has what you > send, > and remote has what you receive (which is what the other end sends). > > > You see the syntax issue in local? The originating MG sees > an > Add with an overspecified local, but returns an overspecified local. > > The terminating MG sees an Add with an overspecified local but > returns a fully specified local. The originating MG doesn't get > a remote with the add. The terminating MG sees an overspecified > remote > which it returns fully specified. > > Brian > > ------_=_NextPart_001_01BF56E0.EFB24426 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

We're getting = close.  Just a couple of points.

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@fore.com]
    Sent:   Tuesday, January 04, 2000 10:11 AM
    To:     Taylor, Tom-PT [CAR:B904:EXCH]; = megaco@standards.nortelnetworks.com
    Subject:       = RE: Proposed Text For Media = Specification

    [[TomT]]  agreed points snipped =

      (3) What is the = meaning of an empty descriptor when sent from the MGC to the MG?=A0 = when sent from the MG to the MGC?=A0=A0

      [BR] First of all, = there is a big difference between empty and not mentioned.=A0 I think = empty from MGC=A0to MG is "I have no=A0policy,=A0tell me all you = can do".=A0 I think empty from MG to MGC is=A0an error.

      =A0
      [[TomT]]  I assume it's not just = "tell me all you can do", but also "reserve resources = for what you tell me about".

    [[TomT]]  ...
     

      (5) Do we accept the = distinction between simultaneous resource commitments (be prepared to = accept/apply any of these at any time) vs. mutually exclusive = commitments (reserve resources to handle any one of these = possibilities, but in the end we'll commit to just one)?=A0 Do we = accept that simultaneous commitments are described within a single = media session description, while mutually exclusive commitments are = described in separate session descriptions?=A0

      [BR] I'm = confused.=A0 I don't understand the distinction, and I don't understand = the=A0syntax differences.=A0=A0To me, the overspecified local=A0with no = remote is "be prepared to accept/apply any of these resources, = reserving whatever resources you might need to do so".=A0 In the = end, you ALWAYS commit to just one.=A0

      [[TomT]] 
      You may alternate, = as in simultaneous use of G.723.1 and the TONES payload.  Thus you = commit to two encodings and corresponding payload types rather than = one.

      Here is the syntax = as I see it:

      v=3D0
      i=3DG.711 = alternative -- the preferred one
      s=3D1
      ...
      m=3Daudio $ RTP/AVP = 0
      v=3D0
      i=3DG.723.1 plus = TONES encoding
      s=3D2
      ...
      m=3Daudio $ RTP/AVP = 4 96
      a=3Drtpmap:96 = X-TONES

      To quote from RFC = 2327 (SDP):

     When a = list of payload formats is given, this implies that all of
     these = formats may be used in the session, but the first of these
     = formats is the default format for the session.

      Thus a single = session description listing G.711, G.723.1, and TONES on the same line = doesn't have the same meaning as what I show above.  I'm proposing = that the above means that the MG must reserve resources to support both = session 1 and session 2 for the moment.  This part is = straightforward.  The next part is special interpretation: that if = multiple session descriptions are given for the same stream, only one = will ever be used, so, for instance, the MG can assign the same port = for every session description.  Can we agree on this = interpretation?    


              -----Original Message-----
      From:=A0=A0 Rosen, Brian = [SMTP:brosen@FORE.COM]
      Sent:=A0=A0 Tuesday, January = 04, 2000 8:28 AM
      To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:=A0=A0=A0=A0=A0=A0=A0 Re: Proposed Text = For Media Specification

              I think buffering is going to be needed if you are = encrypting.
      The real question is whether you = always have to do this, or there
      is some way to know if you might = be.

              The syntax problem is pretty much a "local" = thing.=A0 On the originating end,
      you want to ask for capability.=A0 = On the terminating end, you want to ask the
      MG to make a choice.=A0 In both = cases, it's local that this happens in.=A0 The
      other end gets the result (the = return from the add) as its remote.

              The following is more detail than you need, but I = thought I'd
      write down how I think it works in = great detail for others
      to decide if they agree, or have a = different view:

              More specifically, the originating end gets the = terminating
      end's local as its remote, while = the terminating end gets a
      negotiated version of the = originating end's local as its remote).
      Working this out a little more, = the originating MGC, having no idea what the
      terminating side wants, has only = its local policy. It puts this in local in
      the first Add.=A0 The originating = MG filters this (takes out what it can't
      do), reserving worst case = resources, and
      returns this filtered version of = local in the response to the Add.
      There is no remote at all in this = Add, because the originating MGC
      doesn't know any part of what goes = in remote.

              The originating MGC sends this to the terminating = MGC.=A0 The terminating MG
      filters the received proposal with = its policy,
      and sends it in remote.=A0 If it = will allow asymmetric coding (unusual)
      it could just send its policy in = local, but in most cases, it will
      just present the same coding = options it got from the originating
      end, filtered by it's policy = (which could be reordering, as well
      as removing options) in = local.

              The terminating MG gets the choices and chooses one for = local and
      remote (usually the same, could be = different) if it can and returns
      the single chosen value in the = reply to its add.=A0 If it cannot,
      it means none of the offered = choices are acceptable.=A0 In that case
      it must return an error.=A0 The = response to this error might be
      to attempt the Add again with just = the terminating end's policy,
      which would be returned, and then = the terminating end can propose
      those choices in a full (non fast = start) negotiation.
      Assuming success, the terminating = MGC returns the choice to the originating
      MGC, which modifies the = termination, both in local and
      remote.

              As with the prior discussion, this means local has what = you send,
      and remote has what you receive = (which is what the other end sends). =

              You see the syntax issue in local?=A0 The originating MG = sees an
      Add with an overspecified local, = but returns an overspecified local.
      The terminating MG sees an Add = with an overspecified local but
      returns a fully specified = local.=A0 The originating MG doesn't get
      a remote with the add.=A0 The = terminating MG sees an overspecified remote
      which it returns fully = specified.

              Brian


------_=_NextPart_001_01BF56E0.EFB24426-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 17:43:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08457 for ; Tue, 4 Jan 2000 17:43:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCE0BC00@standards.nortelnetworks.com>; Tue, 4 Jan 2000 17:32:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104724 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 17:31:07 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14F553D0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 17:21:05 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA07159; Tue, 4 Jan 2000 17:31:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA16355; Tue, 4 Jan 2000 17:31:17 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 4 Jan 2000 17:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5703.119B2784" Message-ID: <4FBEA8857476D311A03300204840E1CF0685DB@whq-msgusr-02.fore.com> Date: Tue, 4 Jan 2000 17:31:13 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5703.119B2784 Content-Type: text/plain; charset="iso-8859-1" [[TomT]] agreed points snipped (3) What is the meaning of an empty descriptor when sent from the MGC to the MG? when sent from the MG to the MGC? [BR] First of all, there is a big difference between empty and not mentioned. I think empty from MGC to MG is "I have no policy, tell me all you can do". I think empty from MG to MGC is an error. [[TomT]] I assume it's not just "tell me all you can do", but also "reserve resources for what you tell me about". [BR] Agreed (5) Do we accept the distinction between simultaneous resource commitments (be prepared to accept/apply any of these at any time) vs. mutually exclusive commitments (reserve resources to handle any one of these possibilities, but in the end we'll commit to just one)? Do we accept that simultaneous commitments are described within a single media session description, while mutually exclusive commitments are described in separate session descriptions? [BR] I'm confused. I don't understand the distinction, and I don't understand the syntax differences. To me, the overspecified local with no remote is "be prepared to accept/apply any of these resources, reserving whatever resources you might need to do so". In the end, you ALWAYS commit to just one. [[TomT]] You may alternate, as in simultaneous use of G.723.1 and the TONES payload. Thus you commit to two encodings and corresponding payload types rather than one. Here is the syntax as I see it: v=0 i=G.711 alternative -- the preferred one s=1 ... m=audio $ RTP/AVP 0 v=0 i=G.723.1 plus TONES encoding s=2 ... m=audio $ RTP/AVP 4 96 a=rtpmap:96 X-TONES To quote from RFC 2327 (SDP): When a list of payload formats is given, this implies that all of these formats may be used in the session, but the first of these formats is the default format for the session. Thus a single session description listing G.711, G.723.1, and TONES on the same line doesn't have the same meaning as what I show above. I'm proposing that the above means that the MG must reserve resources to support both session 1 and session 2 for the moment. This part is straightforward. The next part is special interpretation: that if multiple session descriptions are given for the same stream, only one will ever be used, so, for instance, the MG can assign the same port for every session description. Can we agree on this interpretation? [BR] I had not realized that SDP had this capability. Given that, I agree. -----Original Message----- From: Rosen, Brian [SMTP:brosen@FORE.COM] Sent: Tuesday, January 04, 2000 8:28 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Proposed Text For Media Specification I think buffering is going to be needed if you are encrypting. The real question is whether you always have to do this, or there is some way to know if you might be. The syntax problem is pretty much a "local" thing. On the originating end, you want to ask for capability. On the terminating end, you want to ask the MG to make a choice. In both cases, it's local that this happens in. The other end gets the result (the return from the add) as its remote. The following is more detail than you need, but I thought I'd write down how I think it works in great detail for others to decide if they agree, or have a different view: More specifically, the originating end gets the terminating end's local as its remote, while the terminating end gets a negotiated version of the originating end's local as its remote). Working this out a little more, the originating MGC, having no idea what the terminating side wants, has only its local policy. It puts this in local in the first Add. The originating MG filters this (takes out what it can't do), reserving worst case resources, and returns this filtered version of local in the response to the Add. There is no remote at all in this Add, because the originating MGC doesn't know any part of what goes in remote. The originating MGC sends this to the terminating MGC. The terminating MG filters the received proposal with its policy, and sends it in remote. If it will allow asymmetric coding (unusual) it could just send its policy in local, but in most cases, it will just present the same coding options it got from the originating end, filtered by it's policy (which could be reordering, as well as removing options) in local. The terminating MG gets the choices and chooses one for local and remote (usually the same, could be different) if it can and returns the single chosen value in the reply to its add. If it cannot, it means none of the offered choices are acceptable. In that case it must return an error. The response to this error might be to attempt the Add again with just the terminating end's policy, which would be returned, and then the terminating end can propose those choices in a full (non fast start) negotiation. Assuming success, the terminating MGC returns the choice to the originating MGC, which modifies the termination, both in local and remote. As with the prior discussion, this means local has what you send, and remote has what you receive (which is what the other end sends). You see the syntax issue in local? The originating MG sees an Add with an overspecified local, but returns an overspecified local. The terminating MG sees an Add with an overspecified local but returns a fully specified local. The originating MG doesn't get a remote with the add. The terminating MG sees an overspecified remote which it returns fully specified. Brian ------_=_NextPart_001_01BF5703.119B2784 Content-Type: text/html; charset="iso-8859-1" RE: Proposed Text For Media Specification

    [[TomT]]  agreed points snipped

      (3) What is the meaning of an empty descriptor when sent from the MGC to the MG?  when sent from the MG to the MGC?  

      [BR] First of all, there is a big difference between empty and not mentioned.  I think empty from MGC to MG is "I have no policy, tell me all you can do".  I think empty from MG to MGC is an error.

       
      [[TomT]]  I assume it's not just "tell me all you can do", but also "reserve resources for what you tell me about".

     [BR] Agreed  
     

      (5) Do we accept the distinction between simultaneous resource commitments (be prepared to accept/apply any of these at any time) vs. mutually exclusive commitments (reserve resources to handle any one of these possibilities, but in the end we'll commit to just one)?  Do we accept that simultaneous commitments are described within a single media session description, while mutually exclusive commitments are described in separate session descriptions? 

      [BR] I'm confused.  I don't understand the distinction, and I don't understand the syntax differences.  To me, the overspecified local with no remote is "be prepared to accept/apply any of these resources, reserving whatever resources you might need to do so".  In the end, you ALWAYS commit to just one. 

      [[TomT]] 
      You may alternate, as in simultaneous use of G.723.1 and the TONES payload.  Thus you commit to two encodings and corresponding payload types rather than one.

      Here is the syntax as I see it:

      v=0
      i=G.711 alternative -- the preferred one
      s=1
      ...
      m=audio $ RTP/AVP 0
      v=0
      i=G.723.1 plus TONES encoding
      s=2
      ...
      m=audio $ RTP/AVP 4 96
      a=rtpmap:96 X-TONES

      To quote from RFC 2327 (SDP):

     When a list of payload formats is given, this implies that all of
     these formats may be used in the session, but the first of these
     formats is the default format for the session.

      Thus a single session description listing G.711, G.723.1, and TONES on the same line doesn't have the same meaning as what I show above.  I'm proposing that the above means that the MG must reserve resources to support both session 1 and session 2 for the moment.  This part is straightforward.  The next part is special interpretation: that if multiple session descriptions are given for the same stream, only one will ever be used, so, for instance, the MG can assign the same port for every session description.  Can we agree on this interpretation?    

      [BR] I had not realized that SDP had this capability.  Given that, I agree.  


              -----Original Message-----
      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
      Sent:   Tuesday, January 04, 2000 8:28 AM
      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:        Re: Proposed Text For Media Specification

              I think buffering is going to be needed if you are encrypting.
      The real question is whether you always have to do this, or there
      is some way to know if you might be.

              The syntax problem is pretty much a "local" thing.  On the originating end,
      you want to ask for capability.  On the terminating end, you want to ask the
      MG to make a choice.  In both cases, it's local that this happens in.  The
      other end gets the result (the return from the add) as its remote.

              The following is more detail than you need, but I thought I'd
      write down how I think it works in great detail for others
      to decide if they agree, or have a different view:

              More specifically, the originating end gets the terminating
      end's local as its remote, while the terminating end gets a
      negotiated version of the originating end's local as its remote).
      Working this out a little more, the originating MGC, having no idea what the
      terminating side wants, has only its local policy. It puts this in local in
      the first Add.  The originating MG filters this (takes out what it can't
      do), reserving worst case resources, and
      returns this filtered version of local in the response to the Add.
      There is no remote at all in this Add, because the originating MGC
      doesn't know any part of what goes in remote.

              The originating MGC sends this to the terminating MGC.  The terminating MG
      filters the received proposal with its policy,
      and sends it in remote.  If it will allow asymmetric coding (unusual)
      it could just send its policy in local, but in most cases, it will
      just present the same coding options it got from the originating
      end, filtered by it's policy (which could be reordering, as well
      as removing options) in local.

              The terminating MG gets the choices and chooses one for local and
      remote (usually the same, could be different) if it can and returns
      the single chosen value in the reply to its add.  If it cannot,
      it means none of the offered choices are acceptable.  In that case
      it must return an error.  The response to this error might be
      to attempt the Add again with just the terminating end's policy,
      which would be returned, and then the terminating end can propose
      those choices in a full (non fast start) negotiation.
      Assuming success, the terminating MGC returns the choice to the originating
      MGC, which modifies the termination, both in local and
      remote.

              As with the prior discussion, this means local has what you send,
      and remote has what you receive (which is what the other end sends).

              You see the syntax issue in local?  The originating MG sees an
      Add with an overspecified local, but returns an overspecified local.
      The terminating MG sees an Add with an overspecified local but
      returns a fully specified local.  The originating MG doesn't get
      a remote with the add.  The terminating MG sees an overspecified remote
      which it returns fully specified.

              Brian


------_=_NextPart_001_01BF5703.119B2784-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 4 21:44:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12566 for ; Tue, 4 Jan 2000 21:44:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66AD0BA0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 21:33:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105255 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 4 Jan 2000 21:32:25 -0500 Received: from sj-mailhub-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3151FCE0@standards.nortelnetworks.com>; Tue, 4 Jan 2000 21:32:25 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id SAA24898; Tue, 4 Jan 2000 18:44:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id SAA19966; Tue, 4 Jan 2000 18:42:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14450.44961.317304.992226@thomasm-u1.cisco.com> Date: Tue, 4 Jan 2000 18:42:41 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Proposed Text For Media Specification X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: > In your second case in step (4), why doesn't the MG converge on the single > selection s3 for Local and Remote? How does it know that it should leave > Local unresolved? You're right. There are two choices: 1) If we want to modify my description that the MG should at each Local descriptor in order and for each descriptor it can accommodate, it should then look into the choices in the Remote descriptor. If it finds a matching descriptor, it should select that SDP alone for both Remote and Local, otherwise it keeps checking the choices within Local against Remote until a match if found, or Local is exhausted. If Local is exhaused, MGt should return the Local descriptors it can accommodate, along with the most prefereable descriptor in Remote. The advantage here is that it preserves MGC priorities while still converging on a symmetric codec in a 3-way handshake. 2) We could leave it the way I have it, for which it would choose s3. If so, would you like me to contrive an example which actually does the negotiation right? Mike > > > -----Original Message----- > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > Sent: Tuesday, January 04, 2000 11:57 AM > [[TomT]] First case snipped. > > > For *asynchronous* negotiation we modify the flow > > slightly: > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > MGC sends initial add to the originator; remote > > unknown. Local choice are policy > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > MGo chooses s1 and s3; can't do s2 because of > > resources > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > MGC adds MGt, sets policy in local, sends > > choices in remote from MGo; note MGC sends > > policy of not using s1 (for whatever reason) > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > MGt firstly notices that Remote has choices. It > > then SHOULD take the intersection of Local and > > Remote's choices and return the most preferable > > choice (ie, first in list). If there is not an > > intersection, MG MUST choose one in Remote and > > send back the choices in Local that it can > > accommodate (s2, s3). > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > MGC modifies MGo with the choices. Note Remote > > is not fully qualified. The MGC MUST at this > > point remember that it needs to do a 4 way > > handshake since it saw choices in remote going > > to MGo > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > MGo acks the Modify, and chooses s3 because it > > still cannot do s2 in remote > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > MGC transmits the final choices to MGt > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > MGt acks the modify and we're going. > > > > Mike > > > > Rosen, Brian writes: > > > I think buffering is going to be needed if you are encrypting. > > > The real question is whether you always have to do this, or there > > > is some way to know if you might be. > > > > > > The syntax problem is pretty much a "local" thing. On the originating > > end, > > > you want to ask for capability. On the terminating end, you want to > > ask the > > > MG to make a choice. In both cases, it's local that this happens in. > > The > > > other end gets the result (the return from the add) as its remote. > > > > > > The following is more detail than you need, but I thought I'd > > > write down how I think it works in great detail for others > > > to decide if they agree, or have a different view: > > > > > > More specifically, the originating end gets the terminating > > > end's local as its remote, while the terminating end gets a > > > negotiated version of the originating end's local as its remote). > > > Working this out a little more, the originating MGC, having no idea > > what the > > > terminating side wants, has only its local policy. It puts this in > > local in > > > the first Add. The originating MG filters this (takes out what it > > can't > > > do), reserving worst case resources, and > > > returns this filtered version of local in the response to the Add. > > > There is no remote at all in this Add, because the originating MGC > > > doesn't know any part of what goes in remote. > > > > > > The originating MGC sends this to the terminating MGC. The terminating > > MG > > > filters the received proposal with its policy, > > > and sends it in remote. If it will allow asymmetric coding (unusual) > > > it could just send its policy in local, but in most cases, it will > > > just present the same coding options it got from the originating > > > end, filtered by it's policy (which could be reordering, as well > > > as removing options) in local. > > > > > > The terminating MG gets the choices and chooses one for local and > > > remote (usually the same, could be different) if it can and returns > > > the single chosen value in the reply to its add. If it cannot, > > > it means none of the offered choices are acceptable. In that case > > > it must return an error. The response to this error might be > > > to attempt the Add again with just the terminating end's policy, > > > which would be returned, and then the terminating end can propose > > > those choices in a full (non fast start) negotiation. > > > Assuming success, the terminating MGC returns the choice to the > > originating > > > MGC, which modifies the termination, both in local and > > > remote. > > > > > > As with the prior discussion, this means local has what you send, > > > and remote has what you receive (which is what the other end sends). > > > > > > You see the syntax issue in local? The originating MG sees an > > > Add with an overspecified local, but returns an overspecified local. > > > The terminating MG sees an Add with an overspecified local but > > > returns a fully specified local. The originating MG doesn't get > > > a remote with the add. The terminating MG sees an overspecified remote > > > which it returns fully specified. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > To: Rosen, Brian > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > Rosen, Brian writes: > > > > > If true, it means if you see media before the modify, then you > > > > > start decoding, and if the modify says something different than > > > > > you implied from the header, it's an error. It isn't necessary to > > > > > wait until you get the modify before you can process the media. > > > > > I suppose that since there is the possibility of asymmetric > > coding, > > > > > you can't send any media until you have the modify. > > > > > > > > That's what I was afraid of. This implies that either > > > > you load all of the proposed codecs (not just > > > > account for their maximum MIPS and ram as you > > > > implied), or you better be able to load the > > > > codec PDQ once you see the first media packet. > > > > > > > > A worse problem is if you want to negotiate > > > > cipher suites with payload encryption. There, > > > > unless cipher suite negotiation is tied to the > > > > type field somehow (it is not in packetcable, > > > > as one data point), you have no clue how the > > > > packet is encrypted, which effectively causes > > > > front end clipping too. > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > necessity, maybe the right thing to do would be > > > > to buffer the packets in the playback buffer > > > > and not process them until the last Modify > > > > came in -- this gives the whole playback > > > > delay for the arrival of the Modify before you > > > > had to drop the packets on the head of the > > > > queue. > > > > > > > > > HOWEVER, this means we need syntax to differentiate between an > > > > > add with policy, respond with capability, and add with policy, > > > > > choose one and respond with your choice. > > > > > > > > Isn't this where Local and Remote come into > > > > play? If I see several choices in Remote (eg > > > > the other side's local), isn't that the trigger > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > Mike > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > I'm willing to follow this thought along a bit further. I > > > > > > think the > > > > > > > concrete difference between the viewpoint I've > > > > documented and the > > > > > > > "policy-capability" viewpoint is this: if the MGC sends > > > > > > down a number of > > > > > > > alternative session descriptions, in my case the MG picks > > > > > > one, while in > > > > > > > Brian's case the MG replies with all the session > > > > > > descriptions it can > > > > > > > currently support. I am willing to accept the latter > > > > > > proposition if we can > > > > > > > all agree on it. From there, I will go forward with > > > > > > Chip's distinction > > > > > > > between the roles of Local and Remote, and I think we'll > > > > > > have a good > > > > > > > sensible result. > > > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > > syntax when you could use SDP to do the same, > > > > > > there are three constraints which we must adhere > > > > > > to: > > > > > > > > > > > > 1) Negotiation must happen with a three way handshake > > > > > > between the MGC and the two MG's: eg > > > > Add(o)/Add(t)/Modify(o) > > > > > > I think that Tom's original proposal does not meet this > > > > > > requirement, though Brian's does. > > > > > > > > > > > > 2) MG's which offer the set of codec alternatives in > > > > > > Brian's proposal MUST NOT be expected to have those > > > > > > coders actually loaded and prepared to process media > > > > > > packets. The MG will only prepare itself for receipt > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > 3) The entire process MUST NOT lead to front end clipping. > > > > > > I'm not sure how you do this given the other constraints > > > > > > other than making it into a 4 way handshake. Maybe > > somebody > > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > >

In your second case in step (4), why doesn't the MG converge on the single selection s3 for Local and Remote?  How does it know that it should leave Local unresolved?

>
    >

    -----Original Message----- >
    From:   Michael Thomas [SMTP:mat@CISCO.COM] >
    Sent:   Tuesday, January 04, 2000 11:57 AM >
    [[TomT]]  First case snipped. >

    > >

    For *asynchronous* negotiation we modify the flow >
    slightly: >

    >
    > >

    1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} >

    > >

       MGC sends initial add to the originator; remote >
       unknown. Local choice are policy >

    > >

    2) MGo->MGC: Add = { Local { s1, s3} Remote {}} >

    > >

       MGo chooses s1 and s3; can't do s2 because of >
       resources >

    > >

    3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} >

    > >

       MGC adds MGt, sets policy in local, sends >
       choices in remote from MGo; note MGC sends >
       policy of not using s1 (for whatever reason) >

    > >

    4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} >

    > >

       MGt firstly notices that Remote has choices. It >
       then SHOULD take the intersection of Local and >
       Remote's choices and return the most preferable >
       choice (ie, first in list). If there is not an >
       intersection, MG MUST choose one in Remote and >
       send back the choices in Local that it can >
       accommodate (s2, s3). >

    > >

    5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} >

    > >

       MGC modifies MGo with the choices. Note Remote >
       is not fully qualified. The MGC MUST at this >
       point remember that it needs to do a 4 way >
       handshake since it saw choices in remote going >
       to MGo >

    > >

    6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} >

    > >

       MGo acks the Modify, and chooses s3 because it >
       still cannot do s2 in remote >

    > >

    7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} >

    > >

       MGC transmits the final  choices to MGt >

    > >

    8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} >

    > >

       MGt acks the modify and we're going. >

    > >

                Mike >

    > >

    Rosen, Brian writes: >
     > I think buffering is going to be needed if you are encrypting. >
     > The real question is whether you always have to do this, or there >
     > is some way to know if you might be. >
     > >
     > The syntax problem is pretty much a "local" thing.  On the originating end, >
     > you want to ask for capability.  On the terminating end, you want to ask the >
     > MG to make a choice.  In both cases, it's local that this happens in.  The >
     > other end gets the result (the return from the add) as its remote. >
     > >
     > The following is more detail than you need, but I thought I'd >
     > write down how I think it works in great detail for others >
     > to decide if they agree, or have a different view: >
     > >
     > More specifically, the originating end gets the terminating >
     > end's local as its remote, while the terminating end gets a >
     > negotiated version of the originating end's local as its remote). >
     > Working this out a little more, the originating MGC, having no idea what the >
     > terminating side wants, has only its local policy. It puts this in local in >
     > the first Add.  The originating MG filters this (takes out what it can't >
     > do), reserving worst case resources, and >
     > returns this filtered version of local in the response to the Add. >
     > There is no remote at all in this Add, because the originating MGC >
     > doesn't know any part of what goes in remote. >
     > >
     > The originating MGC sends this to the terminating MGC.  The terminating MG >
     > filters the received proposal with its policy, >
     > and sends it in remote.  If it will allow asymmetric coding (unusual) >
     > it could just send its policy in local, but in most cases, it will >
     > just present the same coding options it got from the originating >
     > end, filtered by it's policy (which could be reordering, as well >
     > as removing options) in local. >
     > >
     > The terminating MG gets the choices and chooses one for local and >
     > remote (usually the same, could be different) if it can and returns >
     > the single chosen value in the reply to its add.  If it cannot, >
     > it means none of the offered choices are acceptable.  In that case >
     > it must return an error.  The response to this error might be >
     > to attempt the Add again with just the terminating end's policy, >
     > which would be returned, and then the terminating end can propose >
     > those choices in a full (non fast start) negotiation. >
     > Assuming success, the terminating MGC returns the choice to the originating >
     > MGC, which modifies the termination, both in local and >
     > remote. >
     > >
     > As with the prior discussion, this means local has what you send, >
     > and remote has what you receive (which is what the other end sends). >
     > >
     > You see the syntax issue in local?  The originating MG sees an >
     > Add with an overspecified local, but returns an overspecified local. >
     > The terminating MG sees an Add with an overspecified local but >
     > returns a fully specified local.  The originating MG doesn't get >
     > a remote with the add.  The terminating MG sees an overspecified remote >
     > which it returns fully specified. >
     > >
     > Brian >
     > >
     > > -----Original Message----- >
     > > From: Michael Thomas [mailto:mat@cisco.com] >
     > > Sent: Monday, January 03, 2000 6:21 PM >
     > > To: Rosen, Brian >
     > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM >
     > > Subject: Re: Proposed Text For Media Specification >
     > > >
     > > >
     > > Rosen, Brian writes: >
     > >  > If true, it means if you see media before the modify, then you >
     > >  > start decoding, and if the modify says something different than >
     > >  > you implied from the header, it's an error.  It isn't necessary to >
     > >  > wait until you get the modify before you can process the media. >
     > >  > I suppose that since there is the possibility of asymmetric coding, >
     > >  > you can't send any media until you have the modify. >
     > > >
     > >    That's what I was afraid of. This implies that either >
     > >    you load all of the proposed codecs (not just >
     > >    account for their maximum MIPS and ram as you >
     > >    implied), or you  better be able to load the >
     > >    codec PDQ once you see the first media packet. >
     > > >
     > >    A worse problem is if you want to negotiate >
     > >    cipher suites with payload encryption. There, >
     > >    unless cipher suite negotiation is tied to the >
     > >    type field somehow (it is not in packetcable, >
     > >    as one data point), you have no clue how the >
     > >    packet is encrypted, which effectively causes >
     > >    front end clipping too. >
     > > >
     > >    Since a 4-way handshake is a pretty heinous >
     > >    necessity, maybe the right thing to do would be >
     > >    to buffer the packets in the playback buffer >
     > >    and not process them until the last Modify >
     > >    came in -- this gives the whole playback >
     > >    delay for the arrival of the Modify before you >
     > >    had to drop the packets on the head of the >
     > >    queue. >
     > > >
     > >  > HOWEVER, this means we need syntax to differentiate between an >
     > >  > add with policy, respond with capability, and add with policy, >
     > >  > choose one and respond with your choice. >
     > > >
     > >    Isn't this where Local and Remote come into >
     > >    play? If I see several choices in Remote (eg >
     > >    the other side's local), isn't that the trigger >
     > >    for me to choose one? Or am I all screwed up here? >
     > > >
     > >            Mike >
     > >  > >
     > >  > Brian >
     > >  > >
     > >  > > -----Original Message----- >
     > >  > > From: Michael Thomas [mailto:mat@cisco.com] >
     > >  > > Sent: Monday, January 03, 2000 1:47 PM >
     > >  > > To: MEGACO@standards.nortelnetworks.com >
     > >  > > Subject: Re: Proposed Text For Media Specification >
     > >  > > >
     > >  > > >
     > >  > > Tom-PT Taylor writes: >
     > >  > >  > I'm willing to follow this thought along a bit further.  I >
     > >  > > think the >
     > >  > >  > concrete difference between the viewpoint I've >
     > > documented and the >
     > >  > >  > "policy-capability" viewpoint is this: if the MGC sends >
     > >  > > down a number of >
     > >  > >  > alternative session descriptions, in my case the MG picks >
     > >  > > one, while in >
     > >  > >  > Brian's case the MG replies with all the session >
     > >  > > descriptions it can >
     > >  > >  > currently support.  I am willing to accept the latter >
     > >  > > proposition if we can >
     > >  > >  > all agree on it.  From there, I will go forward with >
     > >  > > Chip's distinction >
     > >  > >  > between the roles of Local and Remote, and I think we'll >
     > >  > > have a good >
     > >  > >  > sensible result. >
     > >  > > >
     > >  > >    Aside from the issue of not wanting to recreate >
     > >  > >    syntax when you could use SDP to do the same, >
     > >  > >    there are three constraints which we must adhere >
     > >  > >    to: >
     > >  > > >
     > >  > >    1) Negotiation must happen with a three way handshake >
     > >  > >       between the MGC and the two MG's: eg >
     > > Add(o)/Add(t)/Modify(o) >
     > >  > >       I think that Tom's original proposal does not meet this >
     > >  > >       requirement, though Brian's does. >
     > >  > > >
     > >  > >    2) MG's which offer the set of codec alternatives in >
     > >  > >       Brian's proposal MUST NOT be expected to have those >
     > >  > >       coders actually loaded and prepared to process media >
     > >  > >       packets. The MG will only prepare itself for receipt >
     > >  > >       of packets when it sees a single choice. >
     > >  > > >
     > >  > >    3) The entire process MUST NOT lead to front end clipping. >
     > >  > >       I'm not sure how you do this given the other constraints >
     > >  > >       other than making it into a 4 way handshake. Maybe somebody >
     > >  > >       more clever than me can solve that problem. >
     > >  > > >
     > >  > > >
     > >  > >                   Mike >
     > >  > > >
     > >  > >
     > >  > >
     > > >
     > >
     > >

    >
> > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 5 11:26:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09691 for ; Wed, 5 Jan 2000 11:26:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21ACB910@standards.nortelnetworks.com>; Wed, 5 Jan 2000 11:15:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106567 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 5 Jan 2000 11:13:50 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F0E207E0@standards.nortelnetworks.com>; Wed, 5 Jan 2000 11:13:49 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 5 Jan 2000 10:23:37 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 5 Jan 2000 11:23:28 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 5 Jan 2000 10:23:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5799.30D18134" Message-ID: Date: Wed, 5 Jan 2000 10:23:25 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-cc: Michael Thomas To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5799.30D18134 Content-Type: text/plain; charset="iso-8859-1" I think your first alternative looks reasonable. If I may, I'll restate what you've said with a little amplification, as follows: "When the MG receives a non-empty Remote Descriptor containing multiple session descriptions, it must choose which of these descriptions it will support and indicate its choice in its response to the MGC. It makes this choice according to the following logic: (1) If the MGC did not provide a Local Descriptor in the command and no resources were reserved for media reception by a previous command, then the MG assumes that the stream will be send-only. It selects the first session description in Remote that it supports. (2) If the MGC did not provide a Local Descriptor in the command, but reserved resources by setting Local in a previous command, then the MG compares the reserved resources against Remote and chooses according to the following principles: (a) If possible, the MG establishes a symmetric media flow, with the same encoding for both directions. (b) If multiple choices for symmetric media flows are available, it chooses the one most preferred by the MGC as previously set in Local. (c) If symmetric encoding is not possible, it chooses the first session description in Remote that it supports, and returns that along with the complete list of session descriptions in Local for which it has reserved resources. (3) If the MGC provided an empty Local Descriptor in the command what happens? According to our previous correspondence, it's something like this: the MG chooses the first session description in Remote that it supports, but returns in Local all of the possibilities for which it was able to reserve resources, given the selection in Remote. (4) If the MGC provided a non-empty Local Descriptor, then the MG applies the principles listed in (2) to make a unique choice for both Local and Remote. > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Tuesday, January 04, 2000 9:43 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: Michael Thomas; megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > Tom-PT Taylor writes: > > In your second case in step (4), why doesn't the MG converge on the > single > > selection s3 for Local and Remote? How does it know that it should > leave > > Local unresolved? > > You're right. There are two choices: > > 1) If we want to modify my description that the > MG should at each Local descriptor in order > and for each descriptor it can accommodate, > it should then look into the choices in the > Remote descriptor. If it finds a matching > descriptor, it should select that SDP alone > for both Remote and Local, otherwise it > keeps checking the choices within Local > against Remote until a match if found, or > Local is exhausted. If Local is exhaused, > MGt should return the Local descriptors > it can accommodate, along with the most > prefereable descriptor in Remote. > > The advantage here is that it preserves MGC > priorities while still converging on a symmetric > codec in a 3-way handshake. > > 2) We could leave it the way I have it, for > which it would choose s3. If so, would > you like me to contrive an example which > actually does the negotiation right? > > Mike > > > > > > > -----Original Message----- > > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > > Sent: Tuesday, January 04, 2000 11:57 AM > > [[TomT]] First case snipped. > > > > > For *asynchronous* negotiation we modify the flow > > > slightly: > > > > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > > > MGC sends initial add to the originator; remote > > > unknown. Local choice are policy > > > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > > > MGo chooses s1 and s3; can't do s2 because of > > > resources > > > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > > > MGC adds MGt, sets policy in local, sends > > > choices in remote from MGo; note MGC sends > > > policy of not using s1 (for whatever reason) > > > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > > > MGt firstly notices that Remote has choices. It > > > then SHOULD take the intersection of Local and > > > Remote's choices and return the most preferable > > > choice (ie, first in list). If there is not an > > > intersection, MG MUST choose one in Remote and > > > send back the choices in Local that it can > > > accommodate (s2, s3). > > > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > > > MGC modifies MGo with the choices. Note Remote > > > is not fully qualified. The MGC MUST at this > > > point remember that it needs to do a 4 way > > > handshake since it saw choices in remote going > > > to MGo > > > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > > > MGo acks the Modify, and chooses s3 because it > > > still cannot do s2 in remote > > > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > > > MGC transmits the final choices to MGt > > > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > > > MGt acks the modify and we're going. > > > > > > Mike > > > > > > Rosen, Brian writes: > > > > I think buffering is going to be needed if you are encrypting. > > > > The real question is whether you always have to do this, or there > > > > is some way to know if you might be. > > > > > > > > The syntax problem is pretty much a "local" thing. On the > originating > > > end, > > > > you want to ask for capability. On the terminating end, you want > to > > > ask the > > > > MG to make a choice. In both cases, it's local that this happens > in. > > > The > > > > other end gets the result (the return from the add) as its remote. > > > > > > > > The following is more detail than you need, but I thought I'd > > > > write down how I think it works in great detail for others > > > > to decide if they agree, or have a different view: > > > > > > > > More specifically, the originating end gets the terminating > > > > end's local as its remote, while the terminating end gets a > > > > negotiated version of the originating end's local as its remote). > > > > Working this out a little more, the originating MGC, having no > idea > > > what the > > > > terminating side wants, has only its local policy. It puts this in > > > local in > > > > the first Add. The originating MG filters this (takes out what it > > > can't > > > > do), reserving worst case resources, and > > > > returns this filtered version of local in the response to the Add. > > > > There is no remote at all in this Add, because the originating MGC > > > > doesn't know any part of what goes in remote. > > > > > > > > The originating MGC sends this to the terminating MGC. The > terminating > > > MG > > > > filters the received proposal with its policy, > > > > and sends it in remote. If it will allow asymmetric coding > (unusual) > > > > it could just send its policy in local, but in most cases, it will > > > > just present the same coding options it got from the originating > > > > end, filtered by it's policy (which could be reordering, as well > > > > as removing options) in local. > > > > > > > > The terminating MG gets the choices and chooses one for local and > > > > remote (usually the same, could be different) if it can and > returns > > > > the single chosen value in the reply to its add. If it cannot, > > > > it means none of the offered choices are acceptable. In that case > > > > it must return an error. The response to this error might be > > > > to attempt the Add again with just the terminating end's policy, > > > > which would be returned, and then the terminating end can propose > > > > those choices in a full (non fast start) negotiation. > > > > Assuming success, the terminating MGC returns the choice to the > > > originating > > > > MGC, which modifies the termination, both in local and > > > > remote. > > > > > > > > As with the prior discussion, this means local has what you send, > > > > and remote has what you receive (which is what the other end > sends). > > > > > > > > You see the syntax issue in local? The originating MG sees an > > > > Add with an overspecified local, but returns an overspecified > local. > > > > The terminating MG sees an Add with an overspecified local but > > > > returns a fully specified local. The originating MG doesn't get > > > > a remote with the add. The terminating MG sees an overspecified > remote > > > > which it returns fully specified. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > Rosen, Brian writes: > > > > > > If true, it means if you see media before the modify, then > you > > > > > > start decoding, and if the modify says something different > than > > > > > > you implied from the header, it's an error. It isn't > necessary to > > > > > > wait until you get the modify before you can process the > media. > > > > > > I suppose that since there is the possibility of asymmetric > > > coding, > > > > > > you can't send any media until you have the modify. > > > > > > > > > > That's what I was afraid of. This implies that either > > > > > you load all of the proposed codecs (not just > > > > > account for their maximum MIPS and ram as you > > > > > implied), or you better be able to load the > > > > > codec PDQ once you see the first media packet. > > > > > > > > > > A worse problem is if you want to negotiate > > > > > cipher suites with payload encryption. There, > > > > > unless cipher suite negotiation is tied to the > > > > > type field somehow (it is not in packetcable, > > > > > as one data point), you have no clue how the > > > > > packet is encrypted, which effectively causes > > > > > front end clipping too. > > > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > > necessity, maybe the right thing to do would be > > > > > to buffer the packets in the playback buffer > > > > > and not process them until the last Modify > > > > > came in -- this gives the whole playback > > > > > delay for the arrival of the Modify before you > > > > > had to drop the packets on the head of the > > > > > queue. > > > > > > > > > > > HOWEVER, this means we need syntax to differentiate between > an > > > > > > add with policy, respond with capability, and add with > policy, > > > > > > choose one and respond with your choice. > > > > > > > > > > Isn't this where Local and Remote come into > > > > > play? If I see several choices in Remote (eg > > > > > the other side's local), isn't that the trigger > > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > > > Mike > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [mailto:mat@cisco.com] > > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > > I'm willing to follow this thought along a bit further. > I > > > > > > > think the > > > > > > > > concrete difference between the viewpoint I've > > > > > documented and the > > > > > > > > "policy-capability" viewpoint is this: if the MGC sends > > > > > > > down a number of > > > > > > > > alternative session descriptions, in my case the MG > picks > > > > > > > one, while in > > > > > > > > Brian's case the MG replies with all the session > > > > > > > descriptions it can > > > > > > > > currently support. I am willing to accept the latter > > > > > > > proposition if we can > > > > > > > > all agree on it. From there, I will go forward with > > > > > > > Chip's distinction > > > > > > > > between the roles of Local and Remote, and I think we'll > > > > > > > have a good > > > > > > > > sensible result. > > > > > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > > > syntax when you could use SDP to do the same, > > > > > > > there are three constraints which we must adhere > > > > > > > to: > > > > > > > > > > > > > > 1) Negotiation must happen with a three way handshake > > > > > > > between the MGC and the two MG's: eg > > > > > Add(o)/Add(t)/Modify(o) > > > > > > > I think that Tom's original proposal does not meet > this > > > > > > > requirement, though Brian's does. > > > > > > > > > > > > > > 2) MG's which offer the set of codec alternatives in > > > > > > > Brian's proposal MUST NOT be expected to have those > > > > > > > coders actually loaded and prepared to process media > > > > > > > packets. The MG will only prepare itself for receipt > > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > > > 3) The entire process MUST NOT lead to front end > clipping. > > > > > > > I'm not sure how you do this given the other > constraints > > > > > > > other than making it into a 4 way handshake. Maybe > > > somebody > > > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > >

In your second case in > step (4), why doesn't the MG converge on the single selection s3 for Local > and Remote?  How does it know that it should leave Local > unresolved?

> >
    > >

    -----Original Message----- > >
    From:   SIZE=1 FACE="Arial">Michael Thomas [SMTP:mat@CISCO.COM] > >
    Sent:   SIZE=1 FACE="Arial">Tuesday, January 04, 2000 11:57 AM > >
    FACE="Arial">[[TomT]]  SIZE=2 FACE="Arial"> First case snipped. SIZE=1 FACE="Arial"> > >

    > > > >

    For *asynchronous* negotiation we modify > the flow > >
    slightly: > >

    > >
    > > > >

    1) MGC->MGo: Add { Local { s1, s2, s3} > Remote {}} > >

    > > > >

       MGC sends initial add to the > originator; remote > >
       unknown. Local choice are > policy > >

    > > > >

    2) MGo->MGC: Add = { Local { s1, s3} > Remote {}} > >

    > > > >

       MGo chooses s1 and s3; can't > do s2 because of > >
       resources > >

    > > > >

    3) MGC->MGt: Add { Local { s2, s3} > Remote { s1, s3}} > >

    > > > >

       MGC adds MGt, sets policy in > local, sends > >
       choices in remote from MGo; > note MGC sends > >
       policy of not using s1 (for > whatever reason) > >

    > > > >

    4) MGt->MGC: Add = { Local { s2, s3 } > Remote {s1}} > >

    > > > >

       MGt firstly notices that > Remote has choices. It > >
       then SHOULD take the > intersection of Local and > >
       Remote's choices and return > the most preferable > >
       choice (ie, first in list). > If there is not an > >
       intersection, MG MUST choose > one in Remote and > >
       send back the choices in > Local that it can > >
       accommodate (s2, s3). > >

    > > > >

    5) MGC->MGo: Modify { Local { s1 } > Remote { s2, s3 }} > >

    > > > >

       MGC modifies MGo with the > choices. Note Remote > >
       is not fully qualified. The > MGC MUST at this > >
       point remember that it needs > to do a 4 way > >
       handshake since it saw > choices in remote going > >
       to MGo > >

    > > > >

    6) MGo->MGC: Modify = { Local { s1 } > Remote { s3}} > >

    > > > >

       MGo acks the Modify, and > chooses s3 because it > >
       still cannot do s2 in > remote > >

    > > > >

    7) MGC->MGt: Modify { Local { s3 } > Remote { s1 }} > >

    > > > >

       MGC transmits the final  > choices to MGt > >

    > > > >

    8) MGt->MGC: Modify = { Local { s3 } > Remote { s1}} > >

    > > > >

       MGt acks the modify and we're > going. > >

    > > > >

    FACE="Arial">          & > nbsp; Mike > >

    > > > >

    Rosen, Brian writes: > >
     > I think buffering is going to > be needed if you are encrypting. > >
     > The real question is whether > you always have to do this, or there > >
     > is some way to know if you > might be. > >
     > > >
     > The syntax problem is pretty > much a "local" thing.  On the originating end, > >
     > you want to ask for > capability.  On the terminating end, you want to ask the > >
     > MG to make a choice.  In > both cases, it's local that this happens in.  The > >
     > other end gets the result (the > return from the add) as its remote. > >
     > > >
     > The following is more detail > than you need, but I thought I'd > >
     > write down how I think it > works in great detail for others > >
     > to decide if they agree, or > have a different view: > >
     > > >
     > More specifically, the > originating end gets the terminating > >
     > end's local as its remote, > while the terminating end gets a > >
     > negotiated version of the > originating end's local as its remote). > >
     > Working this out a little > more, the originating MGC, having no idea what the > >
     > terminating side wants, has > only its local policy. It puts this in local in > >
     > the first Add.  The > originating MG filters this (takes out what it can't > >
     > do), reserving worst case > resources, and > >
     > returns this filtered version > of local in the response to the Add. > >
     > There is no remote at all in > this Add, because the originating MGC > >
     > doesn't know any part of what > goes in remote. > >
     > > >
     > The originating MGC sends this > to the terminating MGC.  The terminating MG > >
     > filters the received proposal > with its policy, > >
     > and sends it in remote.  > If it will allow asymmetric coding (unusual) > >
     > it could just send its policy > in local, but in most cases, it will > >
     > just present the same coding > options it got from the originating > >
     > end, filtered by it's policy > (which could be reordering, as well > >
     > as removing options) in > local. > >
     > > >
     > The terminating MG gets the > choices and chooses one for local and > >
     > remote (usually the same, > could be different) if it can and returns > >
     > the single chosen value in the > reply to its add.  If it cannot, > >
     > it means none of the offered > choices are acceptable.  In that case > >
     > it must return an error.  > The response to this error might be > >
     > to attempt the Add again with > just the terminating end's policy, > >
     > which would be returned, and > then the terminating end can propose > >
     > those choices in a full (non > fast start) negotiation. > >
     > Assuming success, the > terminating MGC returns the choice to the originating > >
     > MGC, which modifies the > termination, both in local and > >
     > remote. > >
     > > >
     > As with the prior discussion, > this means local has what you send, > >
     > and remote has what you > receive (which is what the other end sends). > >
     > > >
     > You see the syntax issue in > local?  The originating MG sees an > >
     > Add with an overspecified > local, but returns an overspecified local. > >
     > The terminating MG sees an Add > with an overspecified local but > >
     > returns a fully specified > local.  The originating MG doesn't get > >
     > a remote with the add.  > The terminating MG sees an overspecified remote > >
     > which it returns fully > specified. > >
     > > >
     > Brian > >
     > > >
     > > -----Original > Message----- > >
     > > From: Michael Thomas > [ HREF="mailto:mat@cisco.com">mailto:mat@cisco.com SIZE=2 FACE="Arial">] > >
     > > Sent: Monday, January 03, > 2000 6:21 PM > >
     > > To: Rosen, Brian > >
     > > Cc: > MEGACO@STANDARDS.NORTELNETWORKS.COM > >
     > > Subject: Re: Proposed > Text For Media Specification > >
     > > > >
     > > > >
     > > Rosen, Brian > writes: > >
     > >  > If true, it > means if you see media before the modify, then you > >
     > >  > start > decoding, and if the modify says something different than > >
     > >  > you implied > from the header, it's an error.  It isn't necessary to > >
     > >  > wait until you > get the modify before you can process the media. > >
     > >  > I suppose that > since there is the possibility of asymmetric coding, > >
     > >  > you can't send > any media until you have the modify. > >
     > > > >
     > >    That's > what I was afraid of. This implies that either > >
     > >    you > load all of the proposed codecs (not just > >
     > >    account > for their maximum MIPS and ram as you > >
     > >    > implied), or you  better be able to load the > >
     > >    codec > PDQ once you see the first media packet. > >
     > > > >
     > >    A worse > problem is if you want to negotiate > >
     > >    cipher > suites with payload encryption. There, > >
     > >    unless > cipher suite negotiation is tied to the > >
     > >    type > field somehow (it is not in packetcable, > >
     > >    as one > data point), you have no clue how the > >
     > >    packet > is encrypted, which effectively causes > >
     > >    front > end clipping too. > >
     > > > >
     > >    Since a > 4-way handshake is a pretty heinous > >
     > >    > necessity, maybe the right thing to do would be > >
     > >    to > buffer the packets in the playback buffer > >
     > >    and not > process them until the last Modify > >
     > >    came in > -- this gives the whole playback > >
     > >    delay > for the arrival of the Modify before you > >
     > >    had to > drop the packets on the head of the > >
     > >    > queue. > >
     > > > >
     > >  > HOWEVER, this > means we need syntax to differentiate between an > >
     > >  > add with > policy, respond with capability, and add with policy, > >
     > >  > choose one and > respond with your choice. > >
     > > > >
     > >    Isn't > this where Local and Remote come into > >
     > >    play? > If I see several choices in Remote (eg > >
     > >    the > other side's local), isn't that the trigger > >
     > >    for me > to choose one? Or am I all screwed up here? > >
     > > > >
     > > >            > Mike > >
     > >  > > >
     > >  > Brian > >
     > >  > > >
     > >  > > > -----Original Message----- > >
     > >  > > From: > Michael Thomas [ HREF="mailto:mat@cisco.com">mailto:mat@cisco.com SIZE=2 FACE="Arial">] > >
     > >  > > Sent: > Monday, January 03, 2000 1:47 PM > >
     > >  > > To: > MEGACO@standards.nortelnetworks.com > >
     > >  > > Subject: > Re: Proposed Text For Media Specification > >
     > >  > > > >
     > >  > > > >
     > >  > > Tom-PT > Taylor writes: > >
     > >  > >  > > I'm willing to follow this thought along a bit further.  > I > >
     > >  > > think > the > >
     > >  > >  > > concrete difference between the viewpoint I've > >
     > > documented and the > >
     > >  > >  > > "policy-capability" viewpoint is this: if the MGC > sends > >
     > >  > > down a > number of > >
     > >  > >  > > alternative session descriptions, in my case the MG picks > >
     > >  > > one, > while in > >
     > >  > >  > > Brian's case the MG replies with all the session > >
     > >  > > > descriptions it can > >
     > >  > >  > > currently support.  I am willing to accept the latter > >
     > >  > > > proposition if we can > >
     > >  > >  > > all agree on it.  From there, I will go forward with > >
     > >  > > Chip's > distinction > >
     > >  > >  > > between the roles of Local and Remote, and I think we'll > >
     > >  > > have a > good > >
     > >  > >  > > sensible result. > >
     > >  > > > >
     > >  > > >    Aside from the issue of not wanting to > recreate > >
     > >  > > >    syntax when you could use SDP to do the > same, > >
     > >  > > >    there are three constraints which we must > adhere > >
     > >  > > >    to: > >
     > >  > > > >
     > >  > > >    1) Negotiation must happen with a three way > handshake > >
     > >  > > >       between the MGC and the two MG's: > eg > >
     > > > Add(o)/Add(t)/Modify(o) > >
     > >  > > >       I think that Tom's original > proposal does not meet this > >
     > >  > > >       requirement, though Brian's > does. > >
     > >  > > > >
     > >  > > >    2) MG's which offer the set of codec alternatives > in > >
     > >  > > >       Brian's proposal MUST NOT be > expected to have those > >
     > >  > > >       coders actually loaded and > prepared to process media > >
     > >  > > >       packets. The MG will only prepare > itself for receipt > >
     > >  > > >       of packets when it sees a single > choice. > >
     > >  > > > >
     > >  > > >    3) The entire process MUST NOT lead to front end > clipping. > >
     > >  > > >       I'm not sure how you do this > given the other constraints > >
     > >  > > >       other than making it into a 4 way > handshake. Maybe somebody > >
     > >  > > >       more clever than me can solve > that problem. > >
     > >  > > > >
     > >  > > > >
     > >  > > >           &nbs > p;       Mike > >
     > >  > > > >
     > >  > > >
     > >  > > >
     > > > >
     > > >
     > > >

    > >
> > > > ------_=_NextPart_001_01BF5799.30D18134 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

I think your first = alternative looks reasonable.  If I may, I'll restate what you've = said with a little amplification, as follows:

"When the MG = receives a non-empty Remote Descriptor containing multiple session = descriptions, it must choose which of these descriptions it will = support and indicate its choice in its response to the MGC.  It = makes this choice according to the following logic:

(1) If the MGC did = not provide a Local Descriptor in the command and no resources were = reserved for media reception by a previous command, then the MG assumes = that the stream will be send-only.  It selects the first session = description in Remote that it supports.

(2) If the MGC did = not provide a Local Descriptor in the command, but reserved resources = by setting Local in a previous command, then the MG compares the = reserved resources against Remote and chooses according to the = following principles:

(a) If possible, the = MG establishes a symmetric media flow, with the same encoding for both = directions.

(b) If multiple = choices for symmetric media flows are available, it chooses the one = most preferred by the MGC as previously set in Local.

(c) If symmetric = encoding is not possible, it chooses the first session description in = Remote that it supports, and returns that along with the complete list = of session descriptions in Local for which it has reserved = resources.

(3) If the MGC = provided an empty Local Descriptor in the command what happens?  = According to our previous correspondence, it's something like = this:  the MG chooses the first session description in Remote that = it supports, but returns in Local all of the possibilities for which it = was able to reserve resources, given the selection in = Remote.

(4) If the MGC = provided a non-empty Local Descriptor, then the MG applies the = principles listed in (2) to make a unique choice for both Local and = Remote.

    -----Original Message-----
    From:   Michael Thomas [SMTP:mat@cisco.com]
    Sent:   Tuesday, January 04, 2000 9:43 PM
    To:     Taylor, Tom-PT [CAR:B904:EXCH]
    Cc:     Michael Thomas; = megaco@standards.nortelnetworks.com
    Subject:       = RE: Proposed Text For Media = Specification

    Tom-PT Taylor writes:
     > In your second case in = step (4), why doesn't the MG converge on the single
     > selection s3 for Local and = Remote?  How does it know that it should leave
     > Local unresolved?

    You're right. There are two = choices:

    1) If we want to modify my description = that the
       MG should at each Local = descriptor in order
       and for each descriptor = it can accommodate,
       it should then look into = the choices in the
       Remote descriptor. If it = finds a matching
       descriptor, it should = select that SDP alone
       for both Remote and = Local, otherwise it
       keeps checking the = choices within Local
       against Remote until a = match if found, or
       Local is exhausted. If = Local is exhaused,
       MGt should return the = Local descriptors
       it can accommodate, = along with the most
       prefereable descriptor = in Remote.

       The advantage here is = that it preserves MGC
       priorities while still = converging on a symmetric
       codec in a 3-way = handshake.

    2) We could leave it the way I have = it, for
       which it would choose = s3. If so, would
       you like me to contrive = an example which
       actually does the = negotiation right?

            =           Mike

      
     >
     > > -----Original = Message-----
     > > = From:      Michael Thomas = [SMTP:mat@CISCO.COM]
     > > = Sent:      Tuesday, January 04, 2000 11:57 = AM
     >      = [[TomT]]  First case snipped.
     >
     > > For *asynchronous* = negotiation we modify the flow
     > > slightly:
     > >
     > >
     > > 1) MGC->MGo: Add { = Local { s1, s2, s3} Remote {}}
     > >
     > >    MGC = sends initial add to the originator; remote
     > >    = unknown. Local choice are policy
     > >
     > > 2) MGo->MGC: Add = =3D { Local { s1, s3} Remote {}}
     > >
     > >    MGo = chooses s1 and s3; can't do s2 because of
     > >    = resources
     > >
     > > 3) MGC->MGt: Add { = Local { s2, s3} Remote { s1, s3}}
     > >
     > >    MGC = adds MGt, sets policy in local, sends
     > >    = choices in remote from MGo; note MGC sends
     > >    = policy of not using s1 (for whatever reason)
     > >
     > > 4) MGt->MGC: Add = =3D { Local { s2, s3 } Remote {s1}}
     > >
     > >    MGt = firstly notices that Remote has choices. It
     > >    = then SHOULD take the intersection of Local and
     > >    = Remote's choices and return the most preferable
     > >    = choice (ie, first in list). If there is not an
     > >    = intersection, MG MUST choose one in Remote and
     > >    = send back the choices in Local that it can
     > >    = accommodate (s2, s3).
     > >
     > > 5) MGC->MGo: = Modify { Local { s1 } Remote { s2, s3 }}
     > >
     > >    MGC = modifies MGo with the choices. Note Remote
     > >    is = not fully qualified. The MGC MUST at this
     > >    = point remember that it needs to do a 4 way
     > >    = handshake since it saw choices in remote going
     > >    to = MGo
     > >
     > > 6) MGo->MGC: = Modify =3D { Local { s1 } Remote { s3}}
     > >
     > >    MGo = acks the Modify, and chooses s3 because it
     > >    = still cannot do s2 in remote
     > >
     > > 7) MGC->MGt: = Modify { Local { s3 } Remote { s1 }}
     > >
     > >    MGC = transmits the final  choices to MGt
     > >
     > > 8) MGt->MGC: = Modify =3D { Local { s3 } Remote { s1}}
     > >
     > >    MGt = acks the modify and we're going.
     > >
     > = >           &n= bsp; Mike
     > >
     > > Rosen, Brian = writes:
     > >  > I think = buffering is going to be needed if you are encrypting.
     > >  > The real = question is whether you always have to do this, or there
     > >  > is some = way to know if you might be.
     > >  >
     > >  > The syntax = problem is pretty much a "local" thing.  On the = originating
     > > end,
     > >  > you want = to ask for capability.  On the terminating end, you want to
     > > ask the
     > >  > MG to make = a choice.  In both cases, it's local that this happens in.
     > > The
     > >  > other end = gets the result (the return from the add) as its remote.
     > >  >
     > >  > The = following is more detail than you need, but I thought I'd
     > >  > write down = how I think it works in great detail for others
     > >  > to decide = if they agree, or have a different view:
     > >  >
     > >  > More = specifically, the originating end gets the terminating
     > >  > end's = local as its remote, while the terminating end gets a
     > >  > negotiated = version of the originating end's local as its remote).
     > >  > Working = this out a little more, the originating MGC, having no idea
     > > what the
     > >  > = terminating side wants, has only its local policy. It puts this = in
     > > local in
     > >  > the first = Add.  The originating MG filters this (takes out what it
     > > can't
     > >  > do), = reserving worst case resources, and
     > >  > returns = this filtered version of local in the response to the Add.
     > >  > There is = no remote at all in this Add, because the originating MGC
     > >  > doesn't = know any part of what goes in remote.
     > >  >
     > >  > The = originating MGC sends this to the terminating MGC.  The = terminating
     > > MG
     > >  > filters = the received proposal with its policy,
     > >  > and sends = it in remote.  If it will allow asymmetric coding (unusual)
     > >  > it could = just send its policy in local, but in most cases, it will
     > >  > just = present the same coding options it got from the originating
     > >  > end, = filtered by it's policy (which could be reordering, as well
     > >  > as = removing options) in local.
     > >  >
     > >  > The = terminating MG gets the choices and chooses one for local and
     > >  > remote = (usually the same, could be different) if it can and returns
     > >  > the single = chosen value in the reply to its add.  If it cannot,
     > >  > it means = none of the offered choices are acceptable.  In that case
     > >  > it must = return an error.  The response to this error might be
     > >  > to attempt = the Add again with just the terminating end's policy,
     > >  > which = would be returned, and then the terminating end can propose
     > >  > those = choices in a full (non fast start) negotiation.
     > >  > Assuming = success, the terminating MGC returns the choice to the
     > > originating
     > >  > MGC, which = modifies the termination, both in local and
     > >  > = remote.
     > >  >
     > >  > As with = the prior discussion, this means local has what you send,
     > >  > and remote = has what you receive (which is what the other end sends).
     > >  >
     > >  > You see = the syntax issue in local?  The originating MG sees an
     > >  > Add with = an overspecified local, but returns an overspecified local.
     > >  > The = terminating MG sees an Add with an overspecified local but
     > >  > returns a = fully specified local.  The originating MG doesn't get
     > >  > a remote = with the add.  The terminating MG sees an overspecified = remote
     > >  > which it = returns fully specified.
     > >  >
     > >  > = Brian
     > >  >
     > >  > > = -----Original Message-----
     > >  > > From: = Michael Thomas [mailto:mat@cisco.com]
     > >  > > Sent: = Monday, January 03, 2000 6:21 PM
     > >  > > To: = Rosen, Brian
     > >  > > Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM
     > >  > > = Subject: Re: Proposed Text For Media Specification
     > >  > = >
     > >  > = >
     > >  > > = Rosen, Brian writes:
     > >  > >  = > If true, it means if you see media before the modify, then = you
     > >  > >  = > start decoding, and if the modify says something different = than
     > >  > >  = > you implied from the header, it's an error.  It isn't = necessary to
     > >  > >  = > wait until you get the modify before you can process the = media.
     > >  > >  = > I suppose that since there is the possibility of asymmetric
     > > coding,
     > >  > >  = > you can't send any media until you have the modify.
     > >  > = >
     > >  > = >    That's what I was afraid of. This implies that = either
     > >  > = >    you load all of the proposed codecs (not = just
     > >  > = >    account for their maximum MIPS and ram as = you
     > >  > = >    implied), or you  better be able to load = the
     > >  > = >    codec PDQ once you see the first media = packet.
     > >  > = >
     > >  > = >    A worse problem is if you want to = negotiate
     > >  > = >    cipher suites with payload encryption. = There,
     > >  > = >    unless cipher suite negotiation is tied to = the
     > >  > = >    type field somehow (it is not in = packetcable,
     > >  > = >    as one data point), you have no clue how = the
     > >  > = >    packet is encrypted, which effectively = causes
     > >  > = >    front end clipping too.
     > >  > = >
     > >  > = >    Since a 4-way handshake is a pretty = heinous
     > >  > = >    necessity, maybe the right thing to do would = be
     > >  > = >    to buffer the packets in the playback = buffer
     > >  > = >    and not process them until the last = Modify
     > >  > = >    came in -- this gives the whole playback
     > >  > = >    delay for the arrival of the Modify before = you
     > >  > = >    had to drop the packets on the head of = the
     > >  > = >    queue.
     > >  > = >
     > >  > >  = > HOWEVER, this means we need syntax to differentiate between = an
     > >  > >  = > add with policy, respond with capability, and add with = policy,
     > >  > >  = > choose one and respond with your choice.
     > >  > = >
     > >  > = >    Isn't this where Local and Remote come = into
     > >  > = >    play? If I see several choices in Remote = (eg
     > >  > = >    the other side's local), isn't that the = trigger
     > >  > = >    for me to choose one? Or am I all screwed up = here?
     > >  > = >
     > >  > = >            = Mike
     > >  > >  = >
     > >  > >  = > Brian
     > >  > >  = >
     > >  > >  = > > -----Original Message-----
     > >  > >  = > > From: Michael Thomas [mailto:mat@cisco.com]
     > >  > >  = > > Sent: Monday, January 03, 2000 1:47 PM
     > >  > >  = > > To: MEGACO@standards.nortelnetworks.com
     > >  > >  = > > Subject: Re: Proposed Text For Media Specification
     > >  > >  = > >
     > >  > >  = > >
     > >  > >  = > > Tom-PT Taylor writes:
     > >  > >  = > >  > I'm willing to follow this thought along a bit = further.  I
     > >  > >  = > > think the
     > >  > >  = > >  > concrete difference between the viewpoint = I've
     > >  > > = documented and the
     > >  > >  = > >  > "policy-capability" viewpoint is this: = if the MGC sends
     > >  > >  = > > down a number of
     > >  > >  = > >  > alternative session descriptions, in my case the = MG picks
     > >  > >  = > > one, while in
     > >  > >  = > >  > Brian's case the MG replies with all the = session
     > >  > >  = > > descriptions it can
     > >  > >  = > >  > currently support.  I am willing to accept = the latter
     > >  > >  = > > proposition if we can
     > >  > >  = > >  > all agree on it.  From there, I will go = forward with
     > >  > >  = > > Chip's distinction
     > >  > >  = > >  > between the roles of Local and Remote, and I think = we'll
     > >  > >  = > > have a good
     > >  > >  = > >  > sensible result.
     > >  > >  = > >
     > >  > >  = > >    Aside from the issue of not wanting to = recreate
     > >  > >  = > >    syntax when you could use SDP to do the = same,
     > >  > >  = > >    there are three constraints which we must = adhere
     > >  > >  = > >    to:
     > >  > >  = > >
     > >  > >  = > >    1) Negotiation must happen with a three way = handshake
     > >  > >  = > >       between the MGC and the = two MG's: eg
     > >  > > = Add(o)/Add(t)/Modify(o)
     > >  > >  = > >       I think that Tom's = original proposal does not meet this
     > >  > >  = > >       requirement, though = Brian's does.
     > >  > >  = > >
     > >  > >  = > >    2) MG's which offer the set of codec = alternatives in
     > >  > >  = > >       Brian's proposal MUST NOT = be expected to have those
     > >  > >  = > >       coders actually loaded = and prepared to process media
     > >  > >  = > >       packets. The MG will only = prepare itself for receipt
     > >  > >  = > >       of packets when it sees a = single choice.
     > >  > >  = > >
     > >  > >  = > >    3) The entire process MUST NOT lead to = front end clipping.
     > >  > >  = > >       I'm not sure how you do = this given the other constraints
     > >  > >  = > >       other than making it into = a 4 way handshake. Maybe
     > > somebody
     > >  > >  = > >       more clever than me can = solve that problem.
     > >  > >  = > >
     > >  > >  = > >
     > >  > >  = > = >           &n= bsp;       Mike
     > >  > >  = > >
     > >  > >  = >
     > >  > >  = >
     > >  > = >
     > >  >
     > >  >
     > <!DOCTYPE HTML PUBLIC = "-//W3C//DTD HTML 3.2//EN">
     > <HTML>
     > <HEAD>
     > <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii">
     > <META = NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2448.0">
     > <TITLE>RE: Proposed = Text For Media Specification</TITLE>
     > </HEAD>
     > <BODY>
     >
     > <P><FONT = COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In = your second case in step (4), why doesn't the MG converge on the single = selection s3 for Local and Remote?&nbsp; How does it know that it = should leave Local unresolved?</FONT></P>

     > <UL>
     > <P><FONT SIZE=3D1 = FACE=3D"Arial">-----Original = Message-----</FONT>
     > = <BR><B><FONT SIZE=3D1 = FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B= > <FONT SIZE=3D1 FACE=3D"Arial">Michael Thomas = [SMTP:mat@CISCO.COM]</FONT>

     > <BR><B><FONT = SIZE=3D1 = FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B= > <FONT SIZE=3D1 FACE=3D"Arial">Tuesday, January 04, = 2000 11:57 AM</FONT>

     > = <BR><B><I><FONT COLOR=3D"#0000FF" = SIZE=3D2 = FACE=3D"Arial">[[TomT]]</FONT></I></B><= ;I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial"> First case = snipped.</FONT><B></B><B></B><B><= FONT SIZE=3D1 FACE=3D"Arial"></FONT></B> =

     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">For *asynchronous* negotiation we modify = the flow</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">slightly:</FONT>
     > </P>
     > <BR>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">1) MGC-&gt;MGo: Add { Local { s1, s2, = s3} Remote {}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC sends initial add = to the originator; remote</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; unknown. = Local choice are policy</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">2) MGo-&gt;MGC: Add =3D { Local { s1, = s3} Remote {}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo chooses s1 and s3; = can't do s2 because of</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; = resources</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">3) MGC-&gt;MGt: Add { Local { s2, s3} = Remote { s1, s3}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC adds MGt, sets = policy in local, sends</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; choices in = remote from MGo; note MGC sends</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; policy of not = using s1 (for whatever reason)</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">4) MGt-&gt;MGC: Add =3D { Local { s2, = s3 } Remote {s1}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt firstly notices = that Remote has choices. It</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; then SHOULD = take the intersection of Local and</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Remote's = choices and return the most preferable</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; choice (ie, = first in list). If there is not an</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; intersection, = MG MUST choose one in Remote and</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; send back the = choices in Local that it can</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; accommodate = (s2, s3).</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">5) MGC-&gt;MGo: Modify { Local { s1 } = Remote { s2, s3 }}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC modifies MGo with = the choices. Note Remote</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is not fully = qualified. The MGC MUST at this</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; point = remember that it needs to do a 4 way</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; handshake = since it saw choices in remote going</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; to = MGo</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">6) MGo-&gt;MGC: Modify =3D { Local { s1 = } Remote { s3}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo acks the Modify, = and chooses s3 because it</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; still cannot = do s2 in remote</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">7) MGC-&gt;MGt: Modify { Local { s3 } = Remote { s1 }}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC transmits the = final&nbsp; choices to MGt</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">8) MGt-&gt;MGC: Modify =3D { Local { s3 = } Remote { s1}}</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt acks the modify = and we're going.</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>
     > </P>
     >
     > <P><FONT SIZE=3D2 = FACE=3D"Arial">Rosen, Brian writes:</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; I think = buffering is going to be needed if you are = encrypting.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The real = question is whether you always have to do this, or = there</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; is some way to = know if you might be.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The syntax = problem is pretty much a &quot;local&quot; thing.&nbsp; On = the originating end,</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; you want to ask for = capability.&nbsp; On the terminating end, you want to ask = the</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; MG to make a = choice.&nbsp; In both cases, it's local that this happens = in.&nbsp; The</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; other end gets the = result (the return from the add) as its remote.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The following = is more detail than you need, but I thought I'd</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; write down how = I think it works in great detail for others</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; to decide if = they agree, or have a different view:</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; More = specifically, the originating end gets the = terminating</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; end's local as = its remote, while the terminating end gets a</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; negotiated = version of the originating end's local as its = remote).</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Working this = out a little more, the originating MGC, having no idea what = the</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; terminating side wants, = has only its local policy. It puts this in local = in</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; the first Add.&nbsp; = The originating MG filters this (takes out what it = can't</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; do), reserving worst = case resources, and</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; returns this = filtered version of local in the response to the = Add.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; There is no = remote at all in this Add, because the originating = MGC</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; doesn't know = any part of what goes in remote.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The originating = MGC sends this to the terminating MGC.&nbsp; The terminating = MG</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; filters the received = proposal with its policy,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; and sends it in = remote.&nbsp; If it will allow asymmetric coding = (unusual)</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it could just send its = policy in local, but in most cases, it will</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; just present = the same coding options it got from the originating</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; end, filtered = by it's policy (which could be reordering, as well</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; as removing = options) in local.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The terminating = MG gets the choices and chooses one for local and</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; remote (usually = the same, could be different) if it can and returns</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; the single = chosen value in the reply to its add.&nbsp; If it = cannot,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; it means none = of the offered choices are acceptable.&nbsp; In that = case</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it must return an = error.&nbsp; The response to this error might = be</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; to attempt the = Add again with just the terminating end's policy,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; which would be = returned, and then the terminating end can propose</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; those choices = in a full (non fast start) negotiation.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Assuming = success, the terminating MGC returns the choice to the = originating</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; MGC, which modifies the = termination, both in local and</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = remote.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; As with the = prior discussion, this means local has what you = send,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; and remote has = what you receive (which is what the other end = sends).</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; You see the = syntax issue in local?&nbsp; The originating MG sees = an</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Add with an = overspecified local, but returns an overspecified = local.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The terminating = MG sees an Add with an overspecified local but</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; returns a fully = specified local.&nbsp; The originating MG doesn't = get</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; a remote with the = add.&nbsp; The terminating MG sees an overspecified = remote</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; which it returns fully = specified.</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = Brian</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; = -----Original Message-----</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; From: = Michael Thomas [<U></U></FONT><U><FONT = COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A = HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A></FON= T></U><FONT SIZE=3D2 = FACE=3D"Arial">]</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; Sent: Monday, = January 03, 2000 6:21 PM</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; To: = Rosen, Brian</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; = Subject: Re: Proposed Text For Media Specification</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Rosen, = Brian writes:</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; If true, it means if you see media before = the modify, then you</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; start decoding, and if the modify says something different = than</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; you implied from the header, it's an error.&nbsp; It isn't = necessary to</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; wait until you get the modify before you can process the = media.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; I suppose that since there is the possibility of asymmetric = coding,</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; you can't send any media until you have the = modify.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; That's what I was afraid of. = This implies that either</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; you load all of the proposed = codecs (not just</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; account for their maximum MIPS = and ram as you</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; implied), or you&nbsp; = better be able to load the</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; codec PDQ once you see the first = media packet.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; A worse problem is if you want = to negotiate</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; cipher suites with payload = encryption. There,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; unless cipher suite negotiation = is tied to the</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; type field somehow (it is not in = packetcable,</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; as one data point), you have no = clue how the</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; packet is encrypted, which = effectively causes</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; front end clipping = too.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; Since a 4-way handshake is a = pretty heinous</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; necessity, maybe the right thing = to do would be</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; to buffer the packets in the = playback buffer</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; and not process them until the = last Modify</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; came in -- this gives the whole = playback</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; delay for the arrival of the = Modify before you</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; had to drop the packets on the = head of the</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; queue.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; HOWEVER, this means we need syntax to = differentiate between an</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; add with policy, respond with capability, and add with = policy,</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; choose one and respond with your choice.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; Isn't this where Local and = Remote come into</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; play? If I see several choices = in Remote (eg</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; the other side's local), isn't = that the trigger</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; for me to choose one? Or am I = all screwed up here?</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; Brian</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; -----Original = Message-----</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; From: Michael Thomas = [</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial"><A HREF=3D"mailto:mat@cisco.com">mailto:mat@cisco.com</A></FON= T></U><FONT SIZE=3D2 = FACE=3D"Arial">]</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; Sent: Monday, January 03, 2000 1:47 = PM</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; To: = MEGACO@standards.nortelnetworks.com</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;&nbs= p; &gt; &gt; Subject: Re: Proposed Text For Media = Specification</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; Tom-PT Taylor = writes:</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; I'm willing to = follow this thought along a bit further.&nbsp; = I</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; think the</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; concrete = difference between the viewpoint I've</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; documented and = the</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; = &quot;policy-capability&quot; viewpoint is this: if the MGC = sends</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; down a number of</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; alternative = session descriptions, in my case the MG picks</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; one, while in</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; Brian's case = the MG replies with all the session</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; descriptions it can</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; currently = support.&nbsp; I am willing to accept the = latter</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; proposition if we can</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; all agree on = it.&nbsp; From there, I will go forward = with</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; Chip's distinction</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; between the = roles of Local and Remote, and I think we'll</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; have a good</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; sensible = result.</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; = Aside from the issue of not wanting to recreate</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; syntax when you could = use SDP to do the same,</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; there are three = constraints which we must adhere</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; to:</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 1) = Negotiation must happen with a three way = handshake</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = between the MGC and the two MG's: eg</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; = Add(o)/Add(t)/Modify(o)</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I = think that Tom's original proposal does not meet = this</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = requirement, though Brian's does.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 2) = MG's which offer the set of codec alternatives = in</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Brian's proposal MUST NOT be expected to have = those</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = coders actually loaded and prepared to process = media</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= nbsp; packets. The MG will only prepare itself for = receipt</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of = packets when it sees a single choice.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 3) = The entire process MUST NOT lead to front end = clipping.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = I'm not sure how you do this given the other = constraints</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = other than making it into a 4 way handshake. Maybe = somebody</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = more clever than me can solve that problem.</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>

     > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
     > <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
     > </P>
     > </UL>
     > </BODY>
     > </HTML>

------_=_NextPart_001_01BF5799.30D18134-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 06:51:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07294 for ; Thu, 6 Jan 2000 06:51:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE386EA0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:40:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 06:40:11 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B7AC3A0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 6:30:10 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07100; Thu, 6 Jan 2000 06:40:35 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200001061140.GAA07100@ietf.org> Date: Thu, 6 Jan 2000 06:40:34 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-reqs-10.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Media Gateway Control Working Group of the IETF. Title : Media Gateway control protocol architecture and requirements Author(s) : N. Greene, M. Ramalho, B. Rosen Filename : draft-ietf-megaco-reqs-10.txt Pages : 43 Date : 05-Jan-00 TThis document describes protocol requirements for the Media Gateway control protocol between a Media Gateway Controller and a Media Gateway. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-10.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-megaco-reqs-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-megaco-reqs-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000105110200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-reqs-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-reqs-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000105110200.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 12:36:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17651 for ; Thu, 6 Jan 2000 12:36:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB5ED640@standards.nortelnetworks.com>; Thu, 6 Jan 2000 12:23:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108704 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 12:23:26 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4C22DF0@standards.nortelnetworks.com>; Thu, 6 Jan 2000 12:23:26 -0500 Received: from zrchh190 by smtprich.nortel.com; Thu, 6 Jan 2000 11:33:36 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zrchh190; Thu, 6 Jan 2000 11:39:24 -0600 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 6 Jan 2000 12:31:08 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) X-Orig: Message-ID: Date: Thu, 6 Jan 2000 12:31:04 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Interface Identifier in IUA/M2UA X-cc: rvansche@fore.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM The MGC and MG share a common termination namespace through provisioning. I admit that as a result, the MGC has to have access to a table which maps from routes to sets of names of terminations comprising that route, and the MG has to have a table mapping from termination name to physical appearance. Both of these tables have to be provisioned by the operator. I can't see any way around the route table, and using some sort of standardized naming convention to eliminate the need for the logical-to-physical mapping table would possibly break down for different types of transport. I'm putting this out on the list because other people may wish to comment. > -----Original Message----- > From: Ries [SMTP:rvansche@fore.com] > Sent: Thursday, January 06, 2000 11:44 AM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Subject: RE: Interface Identifier in IUA/M2UA > > > The vendor has no business imposing any semantics at all. That's up to > the > > network operator. > > Then let the network operator define it. Somebody has to know what the > semantics of this FreeFormat String is??? How will this work in real > inter-operating?? > > Ries > -------------------------------------- > Ries van Schelven > Principal Engineer > Marconi > Century House > 100 Upper George's Street > Dun Laoghaire > Co. Dublin > Eire > > Tel: +353 1 2804533 > Fax: +353 1 2804568 > -------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 6 19:10:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25608 for ; Thu, 6 Jan 2000 19:10:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C858190@standards.nortelnetworks.com>; Thu, 6 Jan 2000 18:59:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109574 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 6 Jan 2000 18:58:13 -0500 Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95732600@standards.nortelnetworks.com>; Thu, 6 Jan 2000 18:48:12 -0500 Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10372 for ; Thu, 6 Jan 2000 16:58:34 -0700 (MST) X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38752C3B.231353DF@aztek-eng.com> Date: Thu, 6 Jan 2000 16:58:51 -0700 Reply-To: Jo Friedman Sender: "Media Gateway Control (megaco)" From: Jo Friedman Organization: Aztek Engineering Subject: Analog trunk packages? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Do any drafts exist that define packages for analog trunks? Or is anyone working on this and would be willing to share their ideas? Thanks, Jo Friedman Aztek Engineering, Inc. Boulder CO jo@aztek-eng.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 09:32:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18678 for ; Fri, 7 Jan 2000 09:32:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AF58440@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:21:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110759 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 09:19:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5D20CFD0@standards.nortelnetworks.com>; Fri, 7 Jan 2000 9:19:56 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 7 Jan 2000 08:28:50 -0600 Received: from zrchb213.us.nortel.com by zmers013; Fri, 7 Jan 2000 09:28:31 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 7 Jan 2000 08:28:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF591B.77F8302A" Message-ID: Date: Fri, 7 Jan 2000 08:28:29 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Analog trunk packages? X-To: Jo Friedman To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF591B.77F8302A Content-Type: text/plain We do have the R2 draft (draft-ietf-megaco-R2package-00.txt). We need an MF draft to go along with that. > -----Original Message----- > From: Jo Friedman [SMTP:jo@AZTEK-ENG.COM] > Sent: Thursday, January 06, 2000 6:59 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Analog trunk packages? > > Do any drafts exist that define packages for analog trunks? Or is > anyone working on this and would be willing to share their ideas? > > Thanks, > > Jo Friedman > Aztek Engineering, Inc. Boulder CO > jo@aztek-eng.com ------_=_NextPart_001_01BF591B.77F8302A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Analog trunk packages?

We do have the R2 = draft (draft-ietf-megaco-R2package-00.txt).  We need an MF draft = to go along with that.

    -----Original Message-----
    From:   Jo Friedman [SMTP:jo@AZTEK-ENG.COM]
    Sent:   Thursday, January 06, 2000 6:59 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Analog trunk packages?

    Do any drafts exist that define = packages for analog trunks? Or is
    anyone working on this and would be = willing to share their ideas?

    Thanks,

    Jo Friedman
    Aztek Engineering, Inc. Boulder = CO
    jo@aztek-eng.com

------_=_NextPart_001_01BF591B.77F8302A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 7 10:48:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20645 for ; Fri, 7 Jan 2000 10:48:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.446EC950@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:37:59 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110975 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 7 Jan 2000 10:36:06 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0068B180@standards.nortelnetworks.com>; Fri, 7 Jan 2000 10:36:05 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA08145; Fri, 7 Jan 2000 07:46:24 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000107104443.00b21320@dogwood.cisco.com> Date: Fri, 7 Jan 2000 10:45:58 -0500 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Analog trunk packages? X-To: Jo Friedman To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38752C3B.231353DF@aztek-eng.com> What kind of analog trunks were you thinking of? FX? E&M? SF? N-type? Chip At 04:58 PM 1/6/00 -0700, Jo Friedman wrote: >Do any drafts exist that define packages for analog trunks? Or is >anyone working on this and would be willing to share their ideas? > >Thanks, > >Jo Friedman >Aztek Engineering, Inc. Boulder CO >jo@aztek-eng.com Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Jan 9 17:49:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10717 for ; Sun, 9 Jan 2000 17:49:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.284D5920@standards.nortelnetworks.com>; 9 Jan 2000 17:37:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113862 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 9 Jan 2000 17:35:21 -0500 Received: from sourcenet.org (209.214.98.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.806DD7D0@standards.nortelnetworks.com>; 9 Jan 2000 17:25:19 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <140.68017.117419@sourcenet.org> Date: Sun, 9 Jan 2000 17:35:21 -0500 Reply-To: jeffallen@SOURCENET.ORG Sender: "Media Gateway Control (megaco)" From: jeffallen@SOURCENET.ORG Subject: Good Luck in the New Millenium To: MEGACO@STANDARDS.NORTELNETWORKS.COM To be removed from this mailing list immediately press reply and enter REMOVE on the subject line. Would you like to be able to buy Computers and Software at wholesale? At below what the stores Pay? Reply with "MORE INFO" in the subject field If you are a reseller and would like information on paying what the distributors pay then Reply with Reseller in the subject field. If you have computer products you need to sell then email your details From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 11:25:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07021 for ; Mon, 10 Jan 2000 11:25:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D974B840@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:14:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115394 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 11:13:40 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59CC2AC0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:03:40 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08386 for ; Mon, 10 Jan 2000 11:14:14 -0500 (EST) Received: from mxmail1.xl.com (h135-119-36-104.lucent.com [135.119.36.104]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08370 for ; Mon, 10 Jan 2000 11:14:14 -0500 (EST) Received: by mxmail1.xl.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 11:10:22 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <5E3315C3384FD2118E1400805F6F662B02E0CE8A@mxmail1.xl.com> Date: Mon, 10 Jan 2000 11:10:22 -0500 Reply-To: Seshu Kumar Sender: "Media Gateway Control (megaco)" From: Seshu Kumar Subject: MGCP MF-R2 package. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Does any one of you have the List of Packages, List of Events and Call Flows needed to support MF-R2 signaling, with respect to MGCP (Media Gateway Control Protocol)? I believe the MF package specified in the MGCP document covers only the R1 signaling. Thanx in Advance Seshu ---------------------------------------------------------------------------- ------------------ S V N Sesh Kumar Ghanta Project Leader Onsite Ind-TeleSoft Pvt. Ltd. Lucent Technologies 612, 6th Block Excel Switching Corporation Koramangala 255, Independence Drive Bangalore Hyannis, MA INDIA - 560 095 USA - 02601 email - seshu@indts.com seshukumar@xl.com Phone - +1 (508) 862-3634 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 11:37:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07370 for ; Mon, 10 Jan 2000 11:37:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88420F20@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:26:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 115435 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 11:25:14 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5D6F88E0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 11:25:14 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08649 for ; Mon, 10 Jan 2000 11:35:49 -0500 (EST) Received: from mxmail1.xl.com (h135-119-36-104.lucent.com [135.119.36.104]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA08634 for ; Mon, 10 Jan 2000 11:35:48 -0500 (EST) Received: by mxmail1.xl.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Jan 2000 11:31:52 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: <5E3315C3384FD2118E1400805F6F662B02E0CE8B@mxmail1.xl.com> Date: Mon, 10 Jan 2000 11:31:51 -0500 Reply-To: Seshu Kumar Sender: "Media Gateway Control (megaco)" From: Seshu Kumar Subject: Query w.r.t MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM I need some information regarding Media Gateway behavior with respect to MGCP. When a Media Gateway is processing a 'Requested Event' with multiple actions against it. How should Media Gateway behave when it fails to process one of the actions? Example - "R: hf(S,N)" Required behavior is to swap the connections and notify the occurrence of flash hook. Suppose if swap connections failed due to some reason, How should Media Gateway behave? Should it proceed with notification of 'hf'? But there is no means of reporting the failure of swap connections to Media Gateway Controller. Appreciate an early response. Thanx in Advance Seshu ---------------------------------------------------------------------------- ------------------ S V N Sesh Kumar Ghanta Project Leader Onsite Ind-TeleSoft Pvt. Ltd. Lucent Technologies 612, 6th Block Excel Switching Corporation Koramangala 255, Independence Drive Bangalore Hyannis, MA INDIA - 560 095 USA - 02601 email - seshu@indts.com seshukumar@xl.com Phone - +1 (508) 862-3634 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 15:47:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12153 for ; Mon, 10 Jan 2000 15:47:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35C3A920@standards.nortelnetworks.com>; Mon, 10 Jan 2000 15:34:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116158 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 15:33:35 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0BCED8B0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 15:33:30 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 10 Jan 2000 14:43:21 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 10 Jan 2000 15:42:58 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 15:42:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5BAB.460DDE74" Message-ID: Date: Mon, 10 Jan 2000 15:42:52 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5BAB.460DDE74 Content-Type: text/plain; charset="iso-8859-1" Unfortunately this doesn't seem to be quite the last word. From H.323v2 section 8.1.7 "Fast Connect Procedure", here is how fast connect works. "The calling endpoint initiates the Fast Connect procedure by sending a SETUP message containing the fastStart element to the called endpoint. The fastStart element consists of a sequence of OpenLogicalChannel structures describing media channels which the calling endpoint proposes to send and receive, including all of the parameters necessary to immediately open and begin transferring media on the channels. Details of the content and usage of the fastStart element are discussed below. ... "The called endpoint may begin transmitting media (according to the channels opened) immediately after sending a Q.931 message containing fastStart. The calling endpoint must therefore be prepared to receive media on any of the receive channels it proposed in the SETUP message, since it is possible for the media to be received prior to the Q.931 message indicating precisely which channels will be used. Once a Q.931 message containing fastStart is received by the calling endpoint, the calling endpoint may discontinue attempting to receive media on the channels for which proposals were not accepted by the called endpoint. Note that national requirements may prohibit called endpoints from transmitting media, or limit the nature of the content of the media stream, prior to transmission of a CONNECT message; it is the responsibility of the endpoint to comply with applicable requirements. If the calling endpoint sets the mediaWaitForConnect element to TRUE in the SETUP message, then the called endpoint shall not send any media until after the CONNECT message is sent." Note particularly that the originating end has to reserve resources for both the send and receive directions of flow. This issue here is that the originating end may want to reserve alternatives, leaving the far end to choose from amongst them. This implies a non-empty Remote Descriptor, which according to the rules stated below would cause the originating MG to select a single alternative rather than reserve resources for everything proposed. The answer probably lies in adding a parameter to LocalControl, with the two values "choose" or "reserveAll". If "choose" is specified the rules below are applied. Otherwise the MG reserves resources as specified in Local and Remote according to the listed order of preference, and is prepared to receive any flow listed in Local immediately upon responding to the MGC. One more issue here: what to fill in for the far-end address in Remote, pending a response from the far end? I proposed using dashes earlier, but how about following a convention used in SIP and supplying an address consisting of all zeroes? > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Wednesday, January 05, 2000 11:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > I think your first alternative looks reasonable. If I may, I'll restate > what you've said with a little amplification, as follows: > > "When the MG receives a non-empty Remote Descriptor containing multiple > session descriptions, it must choose which of these descriptions it will > support and indicate its choice in its response to the MGC. It makes this > choice according to the following logic: > > (1) If the MGC did not provide a Local Descriptor in the command and no > resources were reserved for media reception by a previous command, then > the MG assumes that the stream will be send-only. It selects the first > session description in Remote that it supports. > > (2) If the MGC did not provide a Local Descriptor in the command, but > reserved resources by setting Local in a previous command, then the MG > compares the reserved resources against Remote and chooses according to > the following principles: > > (a) If possible, the MG establishes a symmetric media flow, with the same > encoding for both directions. > > (b) If multiple choices for symmetric media flows are available, it > chooses the one most preferred by the MGC as previously set in Local. > > (c) If symmetric encoding is not possible, it chooses the first session > description in Remote that it supports, and returns that along with the > complete list of session descriptions in Local for which it has reserved > resources. > > (3) If the MGC provided an empty Local Descriptor in the command what > happens? According to our previous correspondence, it's something like > this: the MG chooses the first session description in Remote that it > supports, but returns in Local all of the possibilities for which it was > able to reserve resources, given the selection in Remote. > > (4) If the MGC provided a non-empty Local Descriptor, then the MG applies > the principles listed in (2) to make a unique choice for both Local and > Remote. > > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Tuesday, January 04, 2000 9:43 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: Michael Thomas; megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > Tom-PT Taylor writes: > > In your second case in step (4), why doesn't the MG converge on the > single > > selection s3 for Local and Remote? How does it know that it should > leave > > Local unresolved? > > You're right. There are two choices: > > 1) If we want to modify my description that the > MG should at each Local descriptor in order > and for each descriptor it can accommodate, > it should then look into the choices in the > Remote descriptor. If it finds a matching > descriptor, it should select that SDP alone > for both Remote and Local, otherwise it > keeps checking the choices within Local > against Remote until a match if found, or > Local is exhausted. If Local is exhaused, > MGt should return the Local descriptors > it can accommodate, along with the most > prefereable descriptor in Remote. > > The advantage here is that it preserves MGC > priorities while still converging on a symmetric > codec in a 3-way handshake. > > 2) We could leave it the way I have it, for > which it would choose s3. If so, would > you like me to contrive an example which > actually does the negotiation right? > > Mike > > > > > > > -----Original Message----- > > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > > Sent: Tuesday, January 04, 2000 11:57 AM > > [[TomT]] First case snipped. > > > > > For *asynchronous* negotiation we modify the flow > > > slightly: > > > > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > > > MGC sends initial add to the originator; remote > > > unknown. Local choice are policy > > > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > > > MGo chooses s1 and s3; can't do s2 because of > > > resources > > > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > > > MGC adds MGt, sets policy in local, sends > > > choices in remote from MGo; note MGC sends > > > policy of not using s1 (for whatever reason) > > > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > > > MGt firstly notices that Remote has choices. It > > > then SHOULD take the intersection of Local and > > > Remote's choices and return the most preferable > > > choice (ie, first in list). If there is not an > > > intersection, MG MUST choose one in Remote and > > > send back the choices in Local that it can > > > accommodate (s2, s3). > > > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > > > MGC modifies MGo with the choices. Note Remote > > > is not fully qualified. The MGC MUST at this > > > point remember that it needs to do a 4 way > > > handshake since it saw choices in remote going > > > to MGo > > > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > > > MGo acks the Modify, and chooses s3 because it > > > still cannot do s2 in remote > > > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > > > MGC transmits the final choices to MGt > > > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > > > MGt acks the modify and we're going. > > > > > > Mike > > > > > > Rosen, Brian writes: > > > > I think buffering is going to be needed if you are encrypting. > > > > The real question is whether you always have to do this, or there > > > > is some way to know if you might be. > > > > > > > > The syntax problem is pretty much a "local" thing. On the > originating > > > end, > > > > you want to ask for capability. On the terminating end, you want > to > > > ask the > > > > MG to make a choice. In both cases, it's local that this happens > in. > > > The > > > > other end gets the result (the return from the add) as its remote. > > > > > > > > > The following is more detail than you need, but I thought I'd > > > > write down how I think it works in great detail for others > > > > to decide if they agree, or have a different view: > > > > > > > > More specifically, the originating end gets the terminating > > > > end's local as its remote, while the terminating end gets a > > > > negotiated version of the originating end's local as its remote). > > > > Working this out a little more, the originating MGC, having no > idea > > > what the > > > > terminating side wants, has only its local policy. It puts this in > > > > local in > > > > the first Add. The originating MG filters this (takes out what it > > > > can't > > > > do), reserving worst case resources, and > > > > returns this filtered version of local in the response to the Add. > > > > > There is no remote at all in this Add, because the originating MGC > > > > > doesn't know any part of what goes in remote. > > > > > > > > The originating MGC sends this to the terminating MGC. The > terminating > > > MG > > > > filters the received proposal with its policy, > > > > and sends it in remote. If it will allow asymmetric coding > (unusual) > > > > it could just send its policy in local, but in most cases, it will > > > > > just present the same coding options it got from the originating > > > > end, filtered by it's policy (which could be reordering, as well > > > > as removing options) in local. > > > > > > > > The terminating MG gets the choices and chooses one for local and > > > > remote (usually the same, could be different) if it can and > returns > > > > the single chosen value in the reply to its add. If it cannot, > > > > it means none of the offered choices are acceptable. In that case > > > > > it must return an error. The response to this error might be > > > > to attempt the Add again with just the terminating end's policy, > > > > which would be returned, and then the terminating end can propose > > > > those choices in a full (non fast start) negotiation. > > > > Assuming success, the terminating MGC returns the choice to the > > > originating > > > > MGC, which modifies the termination, both in local and > > > > remote. > > > > > > > > As with the prior discussion, this means local has what you send, > > > > and remote has what you receive (which is what the other end > sends). > > > > > > > > You see the syntax issue in local? The originating MG sees an > > > > Add with an overspecified local, but returns an overspecified > local. > > > > The terminating MG sees an Add with an overspecified local but > > > > returns a fully specified local. The originating MG doesn't get > > > > a remote with the add. The terminating MG sees an overspecified > remote > > > > which it returns fully specified. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [ ] > > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > Rosen, Brian writes: > > > > > > If true, it means if you see media before the modify, then > you > > > > > > start decoding, and if the modify says something different > than > > > > > > you implied from the header, it's an error. It isn't > necessary to > > > > > > wait until you get the modify before you can process the > media. > > > > > > I suppose that since there is the possibility of asymmetric > > > coding, > > > > > > you can't send any media until you have the modify. > > > > > > > > > > That's what I was afraid of. This implies that either > > > > > you load all of the proposed codecs (not just > > > > > account for their maximum MIPS and ram as you > > > > > implied), or you better be able to load the > > > > > codec PDQ once you see the first media packet. > > > > > > > > > > A worse problem is if you want to negotiate > > > > > cipher suites with payload encryption. There, > > > > > unless cipher suite negotiation is tied to the > > > > > type field somehow (it is not in packetcable, > > > > > as one data point), you have no clue how the > > > > > packet is encrypted, which effectively causes > > > > > front end clipping too. > > > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > > necessity, maybe the right thing to do would be > > > > > to buffer the packets in the playback buffer > > > > > and not process them until the last Modify > > > > > came in -- this gives the whole playback > > > > > delay for the arrival of the Modify before you > > > > > had to drop the packets on the head of the > > > > > queue. > > > > > > > > > > > HOWEVER, this means we need syntax to differentiate between > an > > > > > > add with policy, respond with capability, and add with > policy, > > > > > > choose one and respond with your choice. > > > > > > > > > > Isn't this where Local and Remote come into > > > > > play? If I see several choices in Remote (eg > > > > > the other side's local), isn't that the trigger > > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > > > Mike > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ ] > > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > > I'm willing to follow this thought along a bit further. > I > > > > > > > think the > > > > > > > > concrete difference between the viewpoint I've > > > > > documented and the > > > > > > > > "policy-capability" viewpoint is this: if the MGC sends > > > > > > > down a number of > > > > > > > > alternative session descriptions, in my case the MG > picks > > > > > > > one, while in > > > > > > > > Brian's case the MG replies with all the session > > > > > > > descriptions it can > > > > > > > > currently support. I am willing to accept the latter > > > > > > > proposition if we can > > > > > > > > all agree on it. From there, I will go forward with > > > > > > > Chip's distinction > > > > > > > > between the roles of Local and Remote, and I think we'll > > > > > > > > have a good > > > > > > > > sensible result. > > > > > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > > > syntax when you could use SDP to do the same, > > > > > > > there are three constraints which we must adhere > > > > > > > to: > > > > > > > > > > > > > > 1) Negotiation must happen with a three way handshake > > > > > > > between the MGC and the two MG's: eg > > > > > Add(o)/Add(t)/Modify(o) > > > > > > > I think that Tom's original proposal does not meet > this > > > > > > > requirement, though Brian's does. > > > > > > > > > > > > > > 2) MG's which offer the set of codec alternatives in > > > > > > > Brian's proposal MUST NOT be expected to have those > > > > > > > coders actually loaded and prepared to process media > > > > > > > packets. The MG will only prepare itself for receipt > > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > > > 3) The entire process MUST NOT lead to front end > clipping. > > > > > > > I'm not sure how you do this given the other > constraints > > > > > > > other than making it into a 4 way handshake. Maybe > > > somebody > > > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > >

In your second case in > step (4), why doesn't the MG converge on the single selection s3 for Local > and Remote?  How does it know that it should leave Local > unresolved?

> > >
    > >

    -----Original Message----- > >
    From:   SIZE=1 FACE="Arial">Michael Thomas [SMTP:mat@CISCO.COM] > > >
    Sent:   > Tuesday, January 04, 2000 11:57 AM > > >
    FACE="Arial">[[TomT]]  SIZE=2 FACE="Arial"> First case snipped. SIZE=1 FACE="Arial"> > > >

    > > > >

    For *asynchronous* negotiation we modify > the flow > >
    slightly: > >

    > >
    > > > >

    1) MGC->MGo: Add { Local { s1, s2, s3} > Remote {}} > >

    > > > >

       MGC sends initial add to the > originator; remote > >
       unknown. Local choice are > policy > >

    > > > >

    2) MGo->MGC: Add = { Local { s1, s3} > Remote {}} > >

    > > > >

       MGo chooses s1 and s3; can't > do s2 because of > >
       resources > >

    > > > >

    3) MGC->MGt: Add { Local { s2, s3} > Remote { s1, s3}} > >

    > > > >

       MGC adds MGt, sets policy in > local, sends > >
       choices in remote from MGo; > note MGC sends > >
       policy of not using s1 (for > whatever reason) > >

    > > > >

    4) MGt->MGC: Add = { Local { s2, s3 } > Remote {s1}} > >

    > > > >

       MGt firstly notices that > Remote has choices. It > >
       then SHOULD take the > intersection of Local and > >
       Remote's choices and return > the most preferable > >
       choice (ie, first in list). > If there is not an > >
       intersection, MG MUST choose > one in Remote and > >
       send back the choices in > Local that it can > >
       accommodate (s2, s3). > > >

    > > > >

    5) MGC->MGo: Modify { Local { s1 } > Remote { s2, s3 }} > >

    > > > >

       MGC modifies MGo with the > choices. Note Remote > >
       is not fully qualified. The > MGC MUST at this > >
       point remember that it needs > to do a 4 way > >
       handshake since it saw > choices in remote going > >
       to MGo > >

    > > > >

    6) MGo->MGC: Modify = { Local { s1 } > Remote { s3}} > >

    > > > >

       MGo acks the Modify, and > chooses s3 because it > >
       still cannot do s2 in > remote > >

    > > > >

    7) MGC->MGt: Modify { Local { s3 } > Remote { s1 }} > >

    > > > >

       MGC transmits the final  > choices to MGt > >

    > > > >

    8) MGt->MGC: Modify = { Local { s3 } > Remote { s1}} > >

    > > > >

       MGt acks the modify and we're > going. > >

    > > > >

    FACE="Arial">          & > nbsp; Mike > >

    > > > >

    Rosen, Brian writes: > >
     > I think buffering is going to > be needed if you are encrypting. > >
     > The real question is whether > you always have to do this, or there > >
     > is some way to know if you > might be. > >
     > > >
     > The syntax problem is pretty > much a "local" thing.  On the originating end, > > >
     > you want to ask for > capability.  On the terminating end, you want to ask the > > >
     > MG to make a > choice.  In both cases, it's local that this happens in.  > The > > >
     > other end gets the > result (the return from the add) as its remote. > >
     > > >
     > The following is more detail > than you need, but I thought I'd > >
     > write down how I think it > works in great detail for others > >
     > to decide if they agree, or > have a different view: > >
     > > >
     > More specifically, the > originating end gets the terminating > >
     > end's local as its remote, > while the terminating end gets a > >
     > negotiated version of the > originating end's local as its remote). > >
     > Working this out a little > more, the originating MGC, having no idea what the > > >
     > terminating side wants, > has only its local policy. It puts this in local in > > >
     > the first Add.  The > originating MG filters this (takes out what it can't > > >
     > do), reserving worst > case resources, and > >
     > returns this filtered version > of local in the response to the Add. > >
     > There is no remote at all in > this Add, because the originating MGC > >
     > doesn't know any part of what > goes in remote. > >
     > > >
     > The originating MGC sends this > to the terminating MGC.  The terminating MG > > >
     > filters the received > proposal with its policy, > >
     > and sends it in remote.  > If it will allow asymmetric coding (unusual) > > >
     > it could just send its > policy in local, but in most cases, it will > >
     > just present the same coding > options it got from the originating > >
     > end, filtered by it's policy > (which could be reordering, as well > >
     > as removing options) in > local. > >
     > > >
     > The terminating MG gets the > choices and chooses one for local and > >
     > remote (usually the same, > could be different) if it can and returns > >
     > the single chosen value in the > reply to its add.  If it cannot, > >
     > it means none of the offered > choices are acceptable.  In that case > > >
     > it must return an > error.  The response to this error might be > >
     > to attempt the Add again with > just the terminating end's policy, > >
     > which would be returned, and > then the terminating end can propose > >
     > those choices in a full (non > fast start) negotiation. > >
     > Assuming success, the > terminating MGC returns the choice to the originating > > >
     > MGC, which modifies the > termination, both in local and > >
     > remote. > >
     > > >
     > As with the prior discussion, > this means local has what you send, > >
     > and remote has what you > receive (which is what the other end sends). > >
     > > >
     > You see the syntax issue in > local?  The originating MG sees an > >
     > Add with an overspecified > local, but returns an overspecified local. > >
     > The terminating MG sees an Add > with an overspecified local but > >
     > returns a fully specified > local.  The originating MG doesn't get > > >
     > a remote with the > add.  The terminating MG sees an overspecified remote > > >
     > which it returns fully > specified. > >
     > > >
     > Brian > >
     > > >
     > > -----Original > Message----- > >
     > > From: Michael Thomas > [ FACE="Arial">] > > >
     > > Sent: Monday, > January 03, 2000 6:21 PM > >
     > > To: Rosen, Brian > >
     > > Cc: > MEGACO@STANDARDS.NORTELNETWORKS.COM > >
     > > Subject: Re: Proposed > Text For Media Specification > >
     > > > >
     > > > >
     > > Rosen, Brian > writes: > >
     > >  > If true, it > means if you see media before the modify, then you > > >
     > >  > start > decoding, and if the modify says something different than > > >
     > >  > you > implied from the header, it's an error.  It isn't necessary to > > >
     > >  > wait > until you get the modify before you can process the media. > > >
     > >  > I > suppose that since there is the possibility of asymmetric coding, > > >
     > >  > you > can't send any media until you have the modify. > >
     > > > >
     > >    That's > what I was afraid of. This implies that either > > >
     > >    > you load all of the proposed codecs (not just > >
     > >    account > for their maximum MIPS and ram as you > >
     > >    > implied), or you  better be able to load the > > >
     > >    > codec PDQ once you see the first media packet. > > >
     > > > >
     > >    A worse > problem is if you want to negotiate > >
     > >    cipher > suites with payload encryption. There, > >
     > >    unless > cipher suite negotiation is tied to the > > >
     > >    > type field somehow (it is not in packetcable, > >
     > >    as one > data point), you have no clue how the > >
     > >    packet > is encrypted, which effectively causes > >
     > >    front > end clipping too. > >
     > > > >
     > >    Since a > 4-way handshake is a pretty heinous > >
     > >    > necessity, maybe the right thing to do would be > > >
     > >    > to buffer the packets in the playback buffer > >
     > >    and not > process them until the last Modify > >
     > >    came in > -- this gives the whole playback > >
     > >    delay > for the arrival of the Modify before you > > >
     > >    > had to drop the packets on the head of the > >
     > >    > queue. > >
     > > > >
     > >  > HOWEVER, this > means we need syntax to differentiate between an > > >
     > >  > add with > policy, respond with capability, and add with policy, > > >
     > >  > choose > one and respond with your choice. > >
     > > > >
     > >    Isn't > this where Local and Remote come into > >
     > >    play? > If I see several choices in Remote (eg > >
     > >    the > other side's local), isn't that the trigger > > >
     > >    > for me to choose one? Or am I all screwed up here? > > >
     > > > >
     > > >            > Mike > > >
     > >  > > >
     > >  > Brian > >
     > >  > > >
     > >  > > > -----Original Message----- > >
     > >  > > From: > Michael Thomas [ HREF=" "> SIZE=2 FACE="Arial">] > > >
     > >  > > > Sent: Monday, January 03, 2000 1:47 PM > >
     > >  > > To: > MEGACO@standards.nortelnetworks.com > >
     > >  > > Subject: > Re: Proposed Text For Media Specification > > >
     > >  > > > > >
     > >  > > > >
     > >  > > Tom-PT > Taylor writes: > >
     > >  > >  > > I'm willing to follow this thought along a bit further.  > I > > >
     > >  > > > think the > >
     > >  > >  > > concrete difference between the viewpoint I've > > >
     > > documented and > the > >
     > >  > >  > > "policy-capability" viewpoint is this: if the MGC > sends > > >
     > >  > > > down a number of > >
     > >  > >  > > alternative session descriptions, in my case the MG picks > > >
     > >  > > > one, while in > >
     > >  > >  > > Brian's case the MG replies with all the session > > >
     > >  > > > descriptions it can > >
     > >  > >  > > currently support.  I am willing to accept the latter > > >
     > >  > > > proposition if we can > >
     > >  > >  > > all agree on it.  From there, I will go forward with > > >
     > >  > > > Chip's distinction > >
     > >  > >  > > between the roles of Local and Remote, and I think we'll > > >
     > >  > > > have a good > >
     > >  > >  > > sensible result. > >
     > >  > > > >
     > >  > > >    Aside from the issue of not wanting to > recreate > > >
     > >  > > >    syntax when you could use SDP to do the > same, > > >
     > >  > > >    there are three constraints which we must > adhere > > >
     > >  > > >    to: > >
     > >  > > > >
     > >  > > >    1) Negotiation must happen with a three way > handshake > > >
     > >  > > >       between the MGC and the two MG's: > eg > > >
     > > > Add(o)/Add(t)/Modify(o) > >
     > >  > > >       I think that Tom's original > proposal does not meet this > > >
     > >  > > >       requirement, though Brian's > does. > > >
     > >  > > > > >
     > >  > > >    2) MG's which offer the set of codec alternatives > in > > >
     > >  > > >       Brian's proposal MUST NOT be > expected to have those > > >
     > >  > > >       coders actually loaded and > prepared to process media > > >
     > >  > > >       packets. The MG will only prepare > itself for receipt > > >
     > >  > > >       of packets when it sees a single > choice. > > >
     > >  > > > > >
     > >  > > >    3) The entire process MUST NOT lead to front end > clipping. > > >
     > >  > > >       I'm not sure how you do this > given the other constraints > > >
     > >  > > >       other than making it into a 4 way > handshake. Maybe somebody > > >
     > >  > > >       more clever than me can solve > that problem. > > >
     > >  > > > > >
     > >  > > > >
     > >  > > >           &nbs > p;       Mike > > >
     > >  > > > > >
     > >  > > >
     > >  > > >
     > > > >
     > > >
     > > >

    > >
> > > > > ------_=_NextPart_001_01BF5BAB.460DDE74 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

Unfortunately this = doesn't seem to be quite the last word.  From H.323v2 section = 8.1.7 "Fast Connect Procedure", here is how fast connect = works.  

<quote>

"The calling endpoint initiates = the Fast Connect procedure by sending a SETUP message containing = the
fastStart element to the called endpoint. The = fastStart element consists of a sequence of
OpenLogicalChannel = structures describing media channels = which the calling endpoint proposes to send
and receive, including all of the = parameters necessary to immediately open and begin transferring
media on the channels. Details of the = content and usage of the fastStart element are discussed below.
...
"The called endpoint may begin = transmitting media (according to the channels opened) = immediately
after sending a Q.931 message = containing fastStart. The = calling endpoint must therefore be prepared
to receive media on any of the = receive channels it proposed in the SETUP message, = since it is possible
for the media to be received prior to = the Q.931 message indicating precisely which channels will be
used. Once a Q.931 message = containing fastStart = is received by the calling endpoint, the = calling
endpoint may discontinue attempting = to receive media on the channels for which proposals were not
accepted by the called endpoint. Note = that national requirements may prohibit called endpoints from
transmitting media, or limit the = nature of the content of the media stream, prior to transmission of = a
CONNECT message; it is the responsibility of the endpoint to = comply with applicable requirements. If
the calling endpoint sets = the mediaWaitForConnect element to TRUE in the SETUP message, = then the
called endpoint shall not send any = media until after the CONNECT message = is sent."

</quote>

Note particularly = that the originating end has to reserve resources for both the send and = receive directions of flow.  This issue here is that the = originating end may want to reserve alternatives, leaving the far end = to choose from amongst them.  This implies a non-empty Remote = Descriptor, which according to the rules stated below would cause the = originating MG to select a single alternative rather than reserve = resources for everything proposed.

The answer probably = lies in adding a parameter to LocalControl, with the two values = "choose" or "reserveAll".  If = "choose" is specified the rules below are applied.  = Otherwise the MG reserves resources as specified in Local and Remote = according to the listed order of preference, and is prepared to receive = any flow listed in Local immediately upon responding to the = MGC.

One more issue = here:  what to fill in for the far-end address in Remote, pending = a response from the far end?  I proposed using dashes earlier, but = how about following a convention used in SIP and supplying an address = consisting of all zeroes?

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Wednesday, January 05, 2000 11:23 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Proposed Text For Media = Specification

    I think your first = alternative looks reasonable.=A0 If I may, I'll restate what you've = said with a little amplification, as follows:

    "When the MG = receives a non-empty Remote Descriptor containing multiple session = descriptions, it must choose which of these descriptions it will = support and indicate its choice in its response to the MGC.=A0 It makes = this choice according to the following logic:

    (1) If the MGC did = not provide a Local Descriptor in the command and no resources were = reserved for media reception by a previous command, then the MG assumes = that the stream will be send-only.=A0 It selects the first session = description in Remote that it supports.

    (2) If the MGC did = not provide a Local Descriptor in the command, but reserved resources = by setting Local in a previous command, then the MG compares the = reserved resources against Remote and chooses according to the = following principles:

    (a) If possible, the = MG establishes a symmetric media flow, with the same encoding for both = directions.

    (b) If multiple = choices for symmetric media flows are available, it chooses the one = most preferred by the MGC as previously set in Local.

    (c) If symmetric = encoding is not possible, it chooses the first session description in = Remote that it supports, and returns that along with the complete list = of session descriptions in Local for which it has reserved = resources.

    (3) If the MGC = provided an empty Local Descriptor in the command what happens?=A0 = According to our previous correspondence, it's something like this:=A0 = the MG chooses the first session description in Remote that it = supports, but returns in Local all of the possibilities for which it = was able to reserve resources, given the selection in = Remote.

    (4) If the MGC = provided a non-empty Local Descriptor, then the MG applies the = principles listed in (2) to make a unique choice for both Local and = Remote.

            -----Original Message-----
    From:=A0=A0 Michael Thomas = [SMTP:mat@cisco.com]
    Sent:=A0=A0 Tuesday, January = 04, 2000 9:43 PM
    To:=A0=A0=A0=A0 Taylor, Tom-PT = [CAR:B904:EXCH]
    Cc:=A0=A0=A0=A0 Michael Thomas; = megaco@standards.nortelnetworks.com
    Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Proposed Text = For Media Specification

            Tom-PT Taylor writes:
    =A0> In your second case in = step (4), why doesn't the MG converge on the single
    =A0> selection s3 for Local and = Remote?=A0 How does it know that it should leave
    =A0> Local = unresolved?

            You're right. There are two choices:

            1) If we want to modify my description that = the
    =A0=A0 MG should at each Local descriptor = in order
    =A0=A0 and for each descriptor it can = accommodate,
    =A0=A0 it should then look into the = choices in the
    =A0=A0 Remote descriptor. If it finds a = matching
    =A0=A0 descriptor, it should = select that SDP alone
    =A0=A0 for both Remote and Local, = otherwise it
    =A0=A0 keeps checking the choices within = Local
    =A0=A0 against Remote until a match if = found, or
    =A0=A0 Local is exhausted. If = Local is exhaused,
    =A0=A0 MGt should return the Local = descriptors
    =A0=A0 it can accommodate, along = with the most
    =A0=A0 prefereable descriptor in = Remote.

            =A0=A0 The advantage here is that it preserves = MGC
    =A0=A0 priorities while still = converging on a symmetric
    =A0=A0 codec in a 3-way = handshake.

            2) We could leave it the way I have it, for
    =A0=A0 which it would choose s3. If so, = would
    =A0=A0 you like me to contrive an = example which
    =A0=A0 actually does the = negotiation right?=20

            =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0 =A0 Mike

            =A0=A0
    =A0>
    =A0> > -----Original = Message-----
    =A0> > From:=A0=A0=A0=A0=A0 = Michael Thomas [SMTP:mat@CISCO.COM]
    =A0> > Sent:=A0=A0=A0=A0=A0 = Tuesday, January 04, 2000 11:57 AM
    =A0> =A0=A0=A0=A0 [[TomT]]=A0 = First case snipped.
    =A0>
    =A0> > For *asynchronous* = negotiation we modify the flow
    =A0> > slightly:
    =A0> >
    =A0> >
    =A0> > 1) MGC->MGo: Add { Local = { s1, s2, s3} Remote {}}
    =A0> >
    =A0> >=A0=A0=A0 MGC sends initial = add to the originator; remote
    =A0> >=A0=A0=A0 unknown. = Local choice are policy
    =A0> >
    =A0> > 2) MGo->MGC: Add =3D { = Local { s1, s3} Remote {}}
    =A0> >
    =A0> >=A0=A0=A0 MGo chooses s1 and = s3; can't do s2 because of
    =A0> >=A0=A0=A0 = resources
    =A0> >
    =A0> > 3) MGC->MGt: Add { Local = { s2, s3} Remote { s1, s3}}
    =A0> >
    =A0> >=A0=A0=A0 MGC adds MGt, sets = policy in local, sends
    =A0> >=A0=A0=A0 choices in = remote from MGo; note MGC sends
    =A0> >=A0=A0=A0 policy of = not using s1 (for whatever reason)
    =A0> >
    =A0> > 4) MGt->MGC: Add =3D { = Local { s2, s3 } Remote {s1}}
    =A0> >
    =A0> >=A0=A0=A0 MGt firstly notices = that Remote has choices. It
    =A0> >=A0=A0=A0 then SHOULD = take the intersection of Local and
    =A0> >=A0=A0=A0 Remote's = choices and return the most preferable
    =A0> >=A0=A0=A0 choice (ie, = first in list). If there is not an
    =A0> >=A0=A0=A0 = intersection, MG MUST choose one in Remote and
    =A0> >=A0=A0=A0 send back = the choices in Local that it can
    =A0> >=A0=A0=A0 accommodate = (s2, s3).
    =A0> >
    =A0> > 5) MGC->MGo: Modify { = Local { s1 } Remote { s2, s3 }}
    =A0> >
    =A0> >=A0=A0=A0 MGC modifies MGo = with the choices. Note Remote
    =A0> >=A0=A0=A0 is not fully = qualified. The MGC MUST at this
    =A0> >=A0=A0=A0 point = remember that it needs to do a 4 way
    =A0> >=A0=A0=A0 handshake = since it saw choices in remote going
    =A0> >=A0=A0=A0 to = MGo
    =A0> >
    =A0> > 6) MGo->MGC: Modify =3D { = Local { s1 } Remote { s3}}
    =A0> >
    =A0> >=A0=A0=A0 MGo acks the = Modify, and chooses s3 because it
    =A0> >=A0=A0=A0 still cannot = do s2 in remote
    =A0> >
    =A0> > 7) MGC->MGt: Modify { = Local { s3 } Remote { s1 }}
    =A0> >
    =A0> >=A0=A0=A0 MGC transmits the = final=A0 choices to MGt
    =A0> >
    =A0> > 8) MGt->MGC: Modify =3D { = Local { s3 } Remote { s1}}
    =A0> >
    =A0> >=A0=A0=A0 MGt acks the modify = and we're going.
    =A0> >
    =A0> = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mike
    =A0> >
    =A0> > Rosen, Brian = writes:
    =A0> >=A0 > I think = buffering is going to be needed if you are encrypting.
    =A0> >=A0 > The real = question is whether you always have to do this, or there
    =A0> >=A0 > is some way = to know if you might be.
    =A0> >=A0 >
    =A0> >=A0 > The syntax = problem is pretty much a "local" thing.=A0 On the = originating
    =A0> > end,
    =A0> >=A0 > you want to = ask for capability.=A0 On the terminating end, you want to
    =A0> > ask the
    =A0> >=A0 > MG to make a = choice.=A0 In both cases, it's local that this happens in.
    =A0> > The
    =A0> >=A0 > other end = gets the result (the return from the add) as its remote.
    =A0> >=A0 >
    =A0> >=A0 > The following = is more detail than you need, but I thought I'd
    =A0> >=A0 > write down = how I think it works in great detail for others
    =A0> >=A0 > to decide if = they agree, or have a different view:
    =A0> >=A0 >
    =A0> >=A0 > More = specifically, the originating end gets the terminating
    =A0> >=A0 > end's local = as its remote, while the terminating end gets a
    =A0> >=A0 > negotiated = version of the originating end's local as its remote).
    =A0> >=A0 > Working this = out a little more, the originating MGC, having no idea
    =A0> > what the
    =A0> >=A0 > terminating = side wants, has only its local policy. It puts this in
    =A0> > local in
    =A0> >=A0 > the first = Add.=A0 The originating MG filters this (takes out what it
    =A0> > can't
    =A0> >=A0 > do), = reserving worst case resources, and
    =A0> >=A0 > returns this = filtered version of local in the response to the Add.
    =A0> >=A0 > There is no = remote at all in this Add, because the originating MGC
    =A0> >=A0 > doesn't know = any part of what goes in remote.
    =A0> >=A0 >
    =A0> >=A0 > The = originating MGC sends this to the terminating MGC.=A0 The = terminating
    =A0> > MG
    =A0> >=A0 > filters the = received proposal with its policy,
    =A0> >=A0 > and sends it = in remote.=A0 If it will allow asymmetric coding (unusual)
    =A0> >=A0 > it could just = send its policy in local, but in most cases, it will
    =A0> >=A0 > just present = the same coding options it got from the originating
    =A0> >=A0 > end, filtered = by it's policy (which could be reordering, as well
    =A0> >=A0 > as removing = options) in local.
    =A0> >=A0 >
    =A0> >=A0 > The = terminating MG gets the choices and chooses one for local = and
    =A0> >=A0 > remote = (usually the same, could be different) if it can and = returns
    =A0> >=A0 > the single = chosen value in the reply to its add.=A0 If it cannot,
    =A0> >=A0 > it means none = of the offered choices are acceptable.=A0 In that case
    =A0> >=A0 > it must = return an error.=A0 The response to this error might be
    =A0> >=A0 > to attempt = the Add again with just the terminating end's policy,
    =A0> >=A0 > which would = be returned, and then the terminating end can propose
    =A0> >=A0 > those choices = in a full (non fast start) negotiation.
    =A0> >=A0 > Assuming = success, the terminating MGC returns the choice to the
    =A0> > = originating
    =A0> >=A0 > MGC, which = modifies the termination, both in local and
    =A0> >=A0 > = remote.
    =A0> >=A0 >
    =A0> >=A0 > As with the = prior discussion, this means local has what you send,
    =A0> >=A0 > and remote = has what you receive (which is what the other end sends).
    =A0> >=A0 >
    =A0> >=A0 > You see the = syntax issue in local?=A0 The originating MG sees an
    =A0> >=A0 > Add with an = overspecified local, but returns an overspecified local.
    =A0> >=A0 > The = terminating MG sees an Add with an overspecified local but
    =A0> >=A0 > returns a = fully specified local.=A0 The originating MG doesn't get
    =A0> >=A0 > a remote with = the add.=A0 The terminating MG sees an overspecified remote
    =A0> >=A0 > which it = returns fully specified.
    =A0> >=A0 >
    =A0> >=A0 > = Brian
    =A0> >=A0 >
    =A0> >=A0 > > = -----Original Message-----
    =A0> >=A0 > > From: = Michael Thomas [ <mailto:mat@cisco.com>]
    =A0> >=A0 > > Sent: = Monday, January 03, 2000 6:21 PM
    =A0> >=A0 > > To: = Rosen, Brian
    =A0> >=A0 > > Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM
    =A0> >=A0 > > Subject: = Re: Proposed Text For Media Specification
    =A0> >=A0 > = >
    =A0> >=A0 > = >
    =A0> >=A0 > > Rosen, = Brian writes:
    =A0> >=A0 > >=A0 > = If true, it means if you see media before the modify, then = you
    =A0> >=A0 > >=A0 > = start decoding, and if the modify says something different = than
    =A0> >=A0 > >=A0 > = you implied from the header, it's an error.=A0 It isn't necessary = to
    =A0> >=A0 > >=A0 > = wait until you get the modify before you can process the = media.
    =A0> >=A0 > >=A0 > = I suppose that since there is the possibility of asymmetric
    =A0> > coding,
    =A0> >=A0 > >=A0 > = you can't send any media until you have the modify.
    =A0> >=A0 > = >
    =A0> >=A0 > >=A0=A0=A0 = That's what I was afraid of. This implies that either
    =A0> >=A0 > >=A0=A0=A0 = you load all of the proposed codecs (not just
    =A0> >=A0 > >=A0=A0=A0 = account for their maximum MIPS and ram as you
    =A0> >=A0 > >=A0=A0=A0 = implied), or you=A0 better be able to load the
    =A0> >=A0 > >=A0=A0=A0 = codec PDQ once you see the first media packet.
    =A0> >=A0 > = >
    =A0> >=A0 > >=A0=A0=A0 = A worse problem is if you want to negotiate
    =A0> >=A0 > >=A0=A0=A0 = cipher suites with payload encryption. There,
    =A0> >=A0 > >=A0=A0=A0 = unless cipher suite negotiation is tied to the
    =A0> >=A0 > >=A0=A0=A0 = type field somehow (it is not in packetcable,
    =A0> >=A0 > >=A0=A0=A0 = as one data point), you have no clue how the
    =A0> >=A0 > >=A0=A0=A0 = packet is encrypted, which effectively causes
    =A0> >=A0 > >=A0=A0=A0 = front end clipping too.
    =A0> >=A0 > = >
    =A0> >=A0 > >=A0=A0=A0 = Since a 4-way handshake is a pretty heinous
    =A0> >=A0 > >=A0=A0=A0 = necessity, maybe the right thing to do would be
    =A0> >=A0 > >=A0=A0=A0 = to buffer the packets in the playback buffer
    =A0> >=A0 > >=A0=A0=A0 = and not process them until the last Modify
    =A0> >=A0 > >=A0=A0=A0 = came in -- this gives the whole playback
    =A0> >=A0 > >=A0=A0=A0 = delay for the arrival of the Modify before you
    =A0> >=A0 > >=A0=A0=A0 = had to drop the packets on the head of the
    =A0> >=A0 > >=A0=A0=A0 = queue.
    =A0> >=A0 > = >
    =A0> >=A0 > >=A0 > = HOWEVER, this means we need syntax to differentiate between = an
    =A0> >=A0 > >=A0 > = add with policy, respond with capability, and add with = policy,
    =A0> >=A0 > >=A0 > = choose one and respond with your choice.
    =A0> >=A0 > = >
    =A0> >=A0 > >=A0=A0=A0 = Isn't this where Local and Remote come into
    =A0> >=A0 > >=A0=A0=A0 = play? If I see several choices in Remote (eg
    =A0> >=A0 > >=A0=A0=A0 = the other side's local), isn't that the trigger
    =A0> >=A0 > >=A0=A0=A0 = for me to choose one? Or am I all screwed up here?
    =A0> >=A0 > = >
    =A0> >=A0 > = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Mike
    =A0> >=A0 > >=A0 = >
    =A0> >=A0 > >=A0 > = Brian
    =A0> >=A0 > >=A0 = >
    =A0> >=A0 > >=A0 > = > -----Original Message-----
    =A0> >=A0 > >=A0 > = > From: Michael Thomas [ <mailto:mat@cisco.com>]
    =A0> >=A0 > >=A0 > = > Sent: Monday, January 03, 2000 1:47 PM
    =A0> >=A0 > >=A0 > = > To: MEGACO@standards.nortelnetworks.com
    =A0> >=A0 > >=A0 > = > Subject: Re: Proposed Text For Media Specification
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = > Tom-PT Taylor writes:
    =A0> >=A0 > >=A0 > = >=A0 > I'm willing to follow this thought along a bit further.=A0 = I
    =A0> >=A0 > >=A0 > = > think the
    =A0> >=A0 > >=A0 > = >=A0 > concrete difference between the viewpoint I've
    =A0> >=A0 > > = documented and the
    =A0> >=A0 > >=A0 > = >=A0 > "policy-capability" viewpoint is this: if the = MGC sends
    =A0> >=A0 > >=A0 > = > down a number of
    =A0> >=A0 > >=A0 > = >=A0 > alternative session descriptions, in my case the MG = picks
    =A0> >=A0 > >=A0 > = > one, while in
    =A0> >=A0 > >=A0 > = >=A0 > Brian's case the MG replies with all the = session
    =A0> >=A0 > >=A0 > = > descriptions it can
    =A0> >=A0 > >=A0 > = >=A0 > currently support.=A0 I am willing to accept the = latter
    =A0> >=A0 > >=A0 > = > proposition if we can
    =A0> >=A0 > >=A0 > = >=A0 > all agree on it.=A0 From there, I will go forward = with
    =A0> >=A0 > >=A0 > = > Chip's distinction
    =A0> >=A0 > >=A0 > = >=A0 > between the roles of Local and Remote, and I think = we'll
    =A0> >=A0 > >=A0 > = > have a good
    =A0> >=A0 > >=A0 > = >=A0 > sensible result.
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 Aside from the issue of not wanting to = recreate
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 syntax when you could use SDP to do the same,
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 there are three constraints which we must = adhere
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 to:
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 1) Negotiation must happen with a three way = handshake
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 between the MGC and the two MG's: eg
    =A0> >=A0 > > = Add(o)/Add(t)/Modify(o)
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 I think that Tom's original proposal does not = meet this
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 requirement, though Brian's does.
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 2) MG's which offer the set of codec alternatives = in
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 Brian's proposal MUST NOT be expected to have = those
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 coders actually loaded and prepared to process = media
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 packets. The MG will only prepare itself for = receipt
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 of packets when it sees a single = choice.
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >=A0=A0=A0 3) The entire process MUST NOT lead to front end = clipping.
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 I'm not sure how you do this given the other = constraints
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 other than making it into a 4 way handshake. = Maybe
    =A0> > somebody
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0 more clever than me can solve that = problem.
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 > = >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = Mike
    =A0> >=A0 > >=A0 > = >
    =A0> >=A0 > >=A0 = >
    =A0> >=A0 > >=A0 = >
    =A0> >=A0 > = >
    =A0> >=A0 >
    =A0> >=A0 >
    =A0> <!DOCTYPE HTML PUBLIC = "-//W3C//DTD HTML 3.2//EN">
    =A0> <HTML>
    =A0> <HEAD>
    =A0> <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii">
    =A0> <META = NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2448.0">
    =A0> <TITLE>RE: Proposed = Text For Media Specification</TITLE>
    =A0> </HEAD>
    =A0> <BODY>
    =A0>
    =A0> <P><FONT = COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In = your second case in step (4), why doesn't the MG converge on the single = selection s3 for Local and Remote?&nbsp; How does it know that it = should leave Local unresolved?</FONT></P>

            =A0> <UL>
    =A0> <P><FONT SIZE=3D1 = FACE=3D"Arial">-----Original = Message-----</FONT>
    =A0> = <BR><B><FONT SIZE=3D1 = FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B= > <FONT SIZE=3D1 FACE=3D"Arial">Michael Thomas = [SMTP:mat@CISCO.COM]</FONT>

            =A0> <BR><B><FONT SIZE=3D1 = FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B= > <FONT SIZE=3D1 FACE=3D"Arial">Tuesday, January 04, = 2000 11:57 AM</FONT>

            =A0> <BR><B><I><FONT = COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">[[TomT]]</FONT></I></B><= ;I></I>&nbsp;<FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial"> First case = snipped.</FONT><B></B><B></B><B><= FONT SIZE=3D1 = FACE=3D"Arial"></FONT></B>

            =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">For *asynchronous* negotiation we modify = the flow</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">slightly:</FONT>
    =A0> </P>
    =A0> <BR>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">1) MGC-&gt;MGo: Add { Local { s1, s2, = s3} Remote {}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC sends initial add = to the originator; remote</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; unknown. = Local choice are policy</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">2) MGo-&gt;MGC: Add =3D { Local { s1, = s3} Remote {}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo chooses s1 and s3; = can't do s2 because of</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; = resources</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">3) MGC-&gt;MGt: Add { Local { s2, s3} = Remote { s1, s3}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC adds MGt, sets = policy in local, sends</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; choices in = remote from MGo; note MGC sends</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; policy of not = using s1 (for whatever reason)</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">4) MGt-&gt;MGC: Add =3D { Local { s2, = s3 } Remote {s1}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt firstly notices = that Remote has choices. It</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; then SHOULD = take the intersection of Local and</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; Remote's = choices and return the most preferable</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; choice (ie, = first in list). If there is not an</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; intersection, = MG MUST choose one in Remote and</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; send back the = choices in Local that it can</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; accommodate = (s2, s3).</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">5) MGC-&gt;MGo: Modify { Local { s1 } = Remote { s2, s3 }}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC modifies MGo with = the choices. Note Remote</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; is not fully = qualified. The MGC MUST at this</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; point = remember that it needs to do a 4 way</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; handshake = since it saw choices in remote going</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; to = MGo</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">6) MGo-&gt;MGC: Modify =3D { Local { s1 = } Remote { s3}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo acks the Modify, = and chooses s3 because it</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp; still cannot = do s2 in remote</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">7) MGC-&gt;MGt: Modify { Local { s3 } = Remote { s1 }}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC transmits the = final&nbsp; choices to MGt</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">8) MGt-&gt;MGC: Modify =3D { Local { s3 = } Remote { s1}}</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt acks the modify = and we're going.</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>
    =A0> </P>
    =A0>
    =A0> <P><FONT SIZE=3D2 = FACE=3D"Arial">Rosen, Brian = writes:</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; I think = buffering is going to be needed if you are = encrypting.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The real = question is whether you always have to do this, or = there</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; is some way to = know if you might be.</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The syntax = problem is pretty much a &quot;local&quot; thing.&nbsp; On = the originating end,</FONT>

            =A0> <BR><FONT SIZE=3D2 FACE=3D"Arial&qu= ot;>&nbsp;&gt; you want to ask for capability.&nbsp; On = the terminating end, you want to ask the</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; MG to make a = choice.&nbsp; In both cases, it's local that this happens = in.&nbsp; The</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; other end gets the = result (the return from the add) as its = remote.</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The following = is more detail than you need, but I thought = I'd</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; write down how = I think it works in great detail for others</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; to decide if = they agree, or have a different view:</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; More = specifically, the originating end gets the = terminating</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; end's local as = its remote, while the terminating end gets a</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; negotiated = version of the originating end's local as its = remote).</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Working this = out a little more, the originating MGC, having no idea what = the</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; terminating side wants, = has only its local policy. It puts this in local = in</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; the first Add.&nbsp; = The originating MG filters this (takes out what it = can't</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; do), reserving worst = case resources, and</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; returns this = filtered version of local in the response to the = Add.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; There is no = remote at all in this Add, because the originating = MGC</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; doesn't know = any part of what goes in remote.</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The originating = MGC sends this to the terminating MGC.&nbsp; The terminating = MG</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; filters the received = proposal with its policy,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; and sends it in = remote.&nbsp; If it will allow asymmetric coding = (unusual)</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it could just send its = policy in local, but in most cases, it will</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; just present = the same coding options it got from the = originating</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; end, filtered = by it's policy (which could be reordering, as = well</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; as removing = options) in local.</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The terminating = MG gets the choices and chooses one for local = and</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; remote (usually = the same, could be different) if it can and = returns</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; the single = chosen value in the reply to its add.&nbsp; If it = cannot,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; it means none = of the offered choices are acceptable.&nbsp; In that = case</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it must return an = error.&nbsp; The response to this error might = be</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; to attempt the = Add again with just the terminating end's = policy,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; which would be = returned, and then the terminating end can = propose</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; those choices = in a full (non fast start) negotiation.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Assuming = success, the terminating MGC returns the choice to the = originating</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; MGC, which modifies the = termination, both in local and</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; remote.</FONT= >
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; As with the = prior discussion, this means local has what you = send,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; and remote has = what you receive (which is what the other end = sends).</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; You see the = syntax issue in local?&nbsp; The originating MG sees = an</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; Add with an = overspecified local, but returns an overspecified = local.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; The terminating = MG sees an Add with an overspecified local but</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; returns a fully = specified local.&nbsp; The originating MG doesn't = get</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; a remote with the = add.&nbsp; The terminating MG sees an overspecified = remote</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; which it returns fully = specified.</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = Brian</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; = -----Original Message-----</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; From: = Michael Thomas [<U></U></FONT><U><FONT = COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"><A = HREF=3D" <mailto:mat@cisco.com>"<= /U>> <mailto:mat@cisco.com></A><= /FONT></U><FONT SIZE=3D2 = FACE=3D"Arial">]</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; Sent: Monday, = January 03, 2000 6:21 PM</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; To: = Rosen, Brian</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; = Subject: Re: Proposed Text For Media = Specification</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt; Rosen, = Brian writes:</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; If true, it means if you see media before = the modify, then you</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; start decoding, and if the modify says something different = than</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; you implied from the header, it's an error.&nbsp; It isn't = necessary to</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; wait until you get the modify before you can process the = media.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; I suppose that since there is the possibility of asymmetric = coding,</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; you can't send any media until you have the = modify.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; That's what I was afraid of. = This implies that either</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; you load all of the proposed = codecs (not just</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; account for their maximum MIPS = and ram as you</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; implied), or you&nbsp; = better be able to load the</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; codec PDQ once you see the first = media packet.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; A worse problem is if you want = to negotiate</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; cipher suites with payload = encryption. There,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; unless cipher suite negotiation = is tied to the</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; type field somehow (it is not in = packetcable,</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; as one data point), you have no = clue how the</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; packet is encrypted, which = effectively causes</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; front end clipping = too.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; Since a 4-way handshake is a = pretty heinous</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; necessity, maybe the right thing = to do would be</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; to buffer the packets in the = playback buffer</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; and not process them until the = last Modify</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; came in -- this gives the whole = playback</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; delay for the arrival of the = Modify before you</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; had to drop the packets on the = head of the</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; queue.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; HOWEVER, this means we need syntax to = differentiate between an</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; add with policy, respond with capability, and add with = policy,</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; choose one and respond with your = choice.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; Isn't this where Local and = Remote come into</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; play? If I see several choices = in Remote (eg</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; the other side's local), isn't = that the trigger</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp; for me to choose one? Or am I = all screwed up here?</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; Brian</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; -----Original = Message-----</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; From: Michael Thomas = [</FONT><U><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial"><A HREF=3D" <mailto:mat@cisco.com>"<= /U>> <mailto:mat@cisco.com></A><= /FONT></U><FONT SIZE=3D2 = FACE=3D"Arial">]</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; Sent: Monday, January 03, 2000 1:47 = PM</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; To: = MEGACO@standards.nortelnetworks.com</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; Subject: Re: Proposed Text For = Media Specification</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt; Tom-PT Taylor = writes:</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; I'm willing to = follow this thought along a bit further.&nbsp; = I</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; think the</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; concrete = difference between the viewpoint I've</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; documented and = the</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; = &quot;policy-capability&quot; viewpoint is this: if the MGC = sends</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; down a number of</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; alternative = session descriptions, in my case the MG picks</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; one, while in</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; Brian's case = the MG replies with all the session</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; descriptions it can</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; currently = support.&nbsp; I am willing to accept the = latter</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; proposition if we can</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; &gt;&nbs= p; &gt; &gt;&nbsp; &gt; all agree on it.&nbsp; From = there, I will go forward with</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; Chip's distinction</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; between the = roles of Local and Remote, and I think we'll</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt; have a good</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp; &gt; sensible = result.</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; = Aside from the issue of not wanting to recreate</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; syntax when you could = use SDP to do the same,</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; there are three = constraints which we must adhere</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;&nbsp;&nbsp;&nbsp; = to:</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 1) = Negotiation must happen with a three way = handshake</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = between the MGC and the two MG's: eg</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt; = Add(o)/Add(t)/Modify(o)</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I = think that Tom's original proposal does not meet = this</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = requirement, though Brian's does.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 2) = MG's which offer the set of codec alternatives = in</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Brian's proposal MUST NOT be expected to have = those</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = coders actually loaded and prepared to process = media</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = packets. The MG will only prepare itself for = receipt</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of = packets when it sees a single choice.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;&nbsp;&nbsp;&nbsp; 3) = The entire process MUST NOT lead to front end = clipping.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = I'm not sure how you do this given the other = constraints</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = other than making it into a 4 way handshake. Maybe = somebody</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = more clever than me can solve that problem.</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt; = &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n= bsp;&nbsp;&nbsp;&nbsp;&nbsp; = Mike</FONT>

            =A0> <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; &gt;&nbsp; = &gt; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;&nbsp; &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 FACE=3D"Arial">&nbsp;&gt; = &gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> <BR><FONT = SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
    =A0> </P>
    =A0> </UL>
    =A0> </BODY>
    =A0> </HTML>

------_=_NextPart_001_01BF5BAB.460DDE74-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 18:06:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14861 for ; Mon, 10 Jan 2000 18:06:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD8F6800@standards.nortelnetworks.com>; Mon, 10 Jan 2000 17:54:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116422 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 17:52:23 -0500 Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7253FC10@standards.nortelnetworks.com>; Mon, 10 Jan 2000 17:52:22 -0500 Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id RAA09798 for ; Mon, 10 Jan 2000 17:58:08 -0500 (EST) Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by ns01.newbridge.com, id smtpdBAA0wUvEv; Mon Jan 10 17:58:04 2000 Received: from [138.120.49.10] by kanata-mh1.ca.newbridge.com with ESMTP for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 18:02:50 -0500 Received: (from smap@localhost) by affserver.ca.newbridge.com. (8.8.5/8.8.5) id SAA17364 for ; Mon, 10 Jan 2000 18:02:59 -0500 (EST) Received: from unknown(192.168.150.1) by affserver via smap (V1.3) id sma017361; Mon Jan 10 18:02:29 2000 Received: from bridgewatersys.com by bridgewatersys.com (SMI-8.6/SMI-SVR4) id SAA17866; Mon, 10 Jan 2000 18:00:55 -0500 X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/mixed; boundary="------------37E667F8FF22ADA5DCF4134F" Message-ID: <387A6703.C480A533@bridgewatersys.com> Date: Mon, 10 Jan 2000 18:11:00 -0500 Reply-To: Goutam Shaw Sender: "Media Gateway Control (megaco)" From: Goutam Shaw Organization: Bridgewater Systems Corp. Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------37E667F8FF22ADA5DCF4134F Content-Type: multipart/alternative; boundary="------------031590B9E580AC7625158ACA" --------------031590B9E580AC7625158ACA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nancy, I'm sorry for the delayed reply. I thought we had put this matter to rest once and for all after we had the conf. call that was attended by Nancy, Myself, Matt and I think Gunner. According to my opinion what we have in the requirements is not AAA. These are configuration parameters that are call specific and have to be conveyed to the MG before the call is terminated and SHOULD NOT AND CANNOT BE dealt by a AAA server. The parameter should help determine how the call is supposed to be treated and has nothing to with "AAA". I would like to keep section d (of draft-ietf-megaco-reqs-10.txt) as it is, that relates to the ability to configure the call adaptation rate. For example, for a given call a service provider might want to restrict the call to 28.8 kbps based on the call specific policy information. As Tom has mentioned we don't need a unanimous decision all we need is a consensus and I believe we have it (unless I hear any major objection from the mailing list which I haven't heard in the past on this topic). Regards, ..Goutam. Nancy-M Greene wrote: > > > Matt, > Megaco/H.248 is a device control protocol. It is true that for NAS, we > allow the MG itself to contact the AAA server. Yet, there will be > implementations that would have the MGC contact the AAA server. The > requirements in this section allow for the development of a NAS > package IN THE FUTURE, that would allow the information returned from > the AAA server to be passed down to the MG. How this package would be > written is NOT specified in this requirements document. > > As for your comment that ALL your comments regarding the NAS section > have been ignored, this is simply not true! Your comments have been > discussed several times on the mailing list. As editor, I have tried > to come up with compromise text again and again, and every time, you > come back saying I haven't yet succeeded in satisfying your wishes. > > Perhaps it is time for the chair to step in and see if we have rough > consensus on the requirements document or not. > > Your comment on 11.2.1 D is correct. 11.2.1 D will be removed from the > requirements document. > > Also, I don't understand your comment that the requirements document > should change, based on recent discussions of the protocol. We did > update the requirements document based on discussion at the Washington > meeting. Tom is planning to put out a companion I-D that maps the > Megaco/H.248 protocol against the requirements document. > > Nancy > > ------------------------------------------------------------------------- > > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > ---------- > From: Matt Holdrege[SMTP:matt@ASCEND.COM] > Sent: Thursday, December 23, 1999 12:00 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > It's sad to see that all my comments regarding the NAS section > have been > ignored again. So let's go through them one more time and I'll > try to put > more detail into my comments. > > At a high level, NAS requirements should be set by the NAS > requirements > working group. That's where the experts are. Also, it's easy to > see that > there are NO specific NAS requirements for MEGACO. For the basic > purposes > of MEGACO, a NAS is no different than a VoIP gateway. I can see > how you may > want to do some special things with special packages, but nothing > in the > base protocol needs to be NAS specific. > > So let's go through the NAS requirements step by step... > > A. Callback. This is all that's listed. There are many aspects to > callback > which are covered by RADIUS and are a part of the new AAA > requirements. If > all you can list is callback, you should remove this requirement > and leave > it up to AAA where it belongs. > > B. Modem types. This is also handled by RADIUS and AAA. The MG > contacts the > AAA server to instruct it on which modem to use. Remember that > the MGC and > MG are not necessarily in the same management domain. But the MG > DOES trust > it's AAA server. So that is where the information must come from > and it > works best if it is transmitted directly. If you introduce a > proxy, you > introduce a lot of difficulties. The AAA WG is trying to deal > with the > difficulties of proxy and we shouldn't jump ahead of them. > > C. D. E. F. These requirements can and should be covered by a > single > sentence. The Protocol must be able to support Q.931 IE's. F > already kind > of says this. Please be succint and less tutorial. Q.931 IE's are > a basic > requirement of all MG's. Not just NAS's. > > >g. Ability for the MGC to direct the NAS to connect to a > specific tun- > > nel, for example to an LNS, or to an AAA server. > > There are a multitude of tunnel types on the Internet. L2TP, > IPsec, IPinIP, > IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all > the same. > They are handled in different IETF working groups that have > defined their > operation and their setup. The MEGACO WG should not be dictating > how > tunnels get set up. Working groups such as L2TPEXT have defined > RADIUS to > setup their tunnels. > > H. This is already covered in the VoIP section. Reproducing > requirements is > just adding confusion. > > You mention that wiretapping has been removed, yet it is still in > 11.2.1 D. > Whether the MEGACO protocol allows wiretap or not, I don't think > we want > this specific requirement in an RFC. This was discussed at the > Washington > plenary. > > Lastly, I think this document should go through a more lengthy > last call > since we are in the holiday time. We've gone into detail at the > last two > meetings on the protocol itself and this requirements document > doesn't > accurately reflect that. > > At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote: > > >I propose WG Last Call based on this document, with the expiry > two weeks > >hence (24 December). > > > >Changes from the previous version are as follows: > > > >- removed reqt 5.6 c) Support general test capabilities, for > example > >loopbacks through the MG to test DSP operation. > >It was agreed that inward loopbacks are outside the scope of the > protocol > >- they are not part of call control, so would be handled by some > other > >maintenance protocol. Thus the above requirement is deleted. > > > >- reqt 5.7 a) - changed word call to connection > > > >- table in section 11 - removed wiretap > > > >- reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - > didn't mean > >wildcarding, meant instead allowing the gateway to choose (part > of) the > >identifier > > > >The references need to be completed still, and there may be an > editor's > >note or two that should still come out. > >-----Original Message----- From: Internet-Drafts@IETF.ORG > >[SMTP:Internet-Drafts@IETF.ORG] Sent: Friday, December 10, > 1999 8:08 > >AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: > I-D > >ACTION:draft-ietf-megaco-reqs-09.txt > > > >A New Internet-Draft is available from the on-line > Internet-Drafts > >directories. This draft is a work item of the Media Gateway > Control > >Working Group of the IETF. > > > > Title : Media Gateway control protocol > architecture > > and requirements > Author(s) : N. > > Greene, M. Ramalho, B. Rosen Filename : > > draft-ietf-megaco-reqs-09.txt Pages : > > 45 Date : 09-Dec-99 > > > >TThis document describes protocol requirements for the Media > Gateway > >control protocol between a Media Gateway Controller and a Media > Gateway. A > >URL for this Internet-Draft > >is: > > http://w > > >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > > >Internet-Drafts are also available by anonymous FTP. Login with > the > >username "anonymous" and a password of your e-mail address. > After logging > >in, type "cd internet-drafts" and then "get > >draft-ietf-megaco-reqs-09.txt". > > > >A list of Internet-Drafts directories can be found > >in > http://www.ietf.org/shadow.html > or > > ftp://ftp.ietf.org/ietf/1shadow- > > >sites.txt > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: mailserv@ietf.org. In the body > >type: "FILE > /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > > >NOTE: The mail server at ietf.org can return the document > >in MIME-encoded form by using the "mpack" utility. To > use > >this feature, insert the command "ENCODING mime" before > the > >"FILE" command. To decode the response(s), you will > need > >"munpack" or a MIME-compliant mail reader. Different > >MIME-compliant mail readers exhibit different behavior, > > >especially when dealing with "multipart" MIME messages > (i.e. > >documents which have been split up into multiple > messages), so > >check your local documentation on how to manipulate > these messages. > > > >Below is the data which will enable a MIME compliant mail > >reader implementation to automatically retrieve the ASCII > version of > >the Internet-Draft. << Message: >> > --------------031590B9E580AC7625158ACA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Nancy, I'm sorry for the delayed reply. I thought we had put this matter to rest once and for all after we had the conf. call that was attended by Nancy, Myself, Matt and I think Gunner.
According to my opinion what we have in the requirements is not AAA. These are configuration parameters that are call specific and have to be conveyed to the MG before the call is terminated and SHOULD NOT AND CANNOT BE dealt by a AAA server. The parameter should help determine how the call is supposed to be treated and has nothing to with "AAA".
I would like to keep section d (of draft-ietf-megaco-reqs-10.txt)  as it is, that relates to the ability to configure the call adaptation rate. For example, for a given call a service provider might want to restrict the call to 28.8 kbps based on the call specific policy information.

As Tom has mentioned we don't need a unanimous decision all we need is a consensus and I believe we have it (unless I hear any major objection from the mailing list which I haven't heard in the past on this topic).

Regards,
..Goutam.

Nancy-M Greene wrote:

 

Matt,
Megaco/H.248 is a device control protocol. It is true that for NAS, we allow the MG itself to contact the AAA server. Yet, there will be implementations that would have the MGC contact the AAA server. The requirements in this section allow for the development of a NAS package IN THE FUTURE, that would allow the information returned from the AAA server to be passed down to the MG. How this package would be written is NOT specified in this requirements document.

As for your comment that ALL your comments regarding the NAS section have been ignored, this is simply not true! Your comments have been discussed several times on the mailing list. As editor, I have tried to come up with compromise text again and again, and every time, you come back saying I haven't yet succeeded in satisfying your wishes.

Perhaps it is time for the chair to step in and see if we have rough consensus on the requirements document or not.

Your comment on 11.2.1 D is correct. 11.2.1 D will be removed from the requirements document.

Also, I don't understand your comment that the requirements document should change, based on recent discussions of the protocol. We did update the requirements document based on discussion at the Washington meeting. Tom is planning to put out a companion I-D that maps the Megaco/H.248 protocol against the requirements document.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

    ----------
    From:   Matt Holdrege[SMTP:matt@ASCEND.COM]
    Sent:   Thursday, December 23, 1999 12:00 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt

    It's sad to see that all my comments regarding the NAS section have been
    ignored again. So let's go through them one more time and I'll try to put
    more detail into my comments.

    At a high level, NAS requirements should be set by the NAS requirements
    working group. That's where the experts are. Also, it's easy to see that
    there are NO specific NAS requirements for MEGACO. For the basic purposes
    of MEGACO, a NAS is no different than a VoIP gateway. I can see how you may
    want to do some special things with special packages, but nothing in the
    base protocol needs to be NAS specific.

    So let's go through the NAS requirements step by step...

    A. Callback. This is all that's listed. There are many aspects to callback
    which are covered by RADIUS and are a part of the new AAA requirements. If
    all you can list is callback, you should remove this requirement and leave
    it up to AAA where it belongs.

    B. Modem types. This is also handled by RADIUS and AAA. The MG contacts the
    AAA server to instruct it on which modem to use. Remember that the MGC and
    MG are not necessarily in the same management domain. But the MG DOES trust
    it's AAA server. So that is where the information must come from and it
    works best if it is transmitted directly. If you introduce a proxy, you
    introduce a lot of difficulties. The AAA WG is trying to deal with the
    difficulties of proxy and we shouldn't jump ahead of them.

    C. D. E. F. These requirements can and should be covered by a single
    sentence. The Protocol must be able to support Q.931 IE's. F already kind
    of says this. Please be succint and less tutorial. Q.931 IE's are a basic
    requirement of all MG's. Not just NAS's.

     >g.   Ability for the MGC to direct the NAS to connect to a specific tun-
     >     nel, for example to an LNS, or to an AAA server.

    There are a multitude of tunnel types on the Internet. L2TP, IPsec, IPinIP,
    IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all the same.
    They are handled in different IETF working groups that have defined their
    operation and their setup. The MEGACO WG should not be dictating how
    tunnels get set up. Working groups such as L2TPEXT have defined RADIUS to
    setup their tunnels.

    H. This is already covered in the VoIP section. Reproducing requirements is
    just adding confusion.

    You mention that wiretapping has been removed, yet it is still in 11.2.1 D.
    Whether the MEGACO protocol allows wiretap or not, I don't think we want
    this specific requirement in an RFC. This was discussed at the Washington
    plenary.

    Lastly, I think this document should go through a more lengthy last call
    since we are in the holiday time. We've gone into detail at the last two
    meetings on the protocol itself and this requirements document doesn't
    accurately reflect that.

    At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote:

    >I propose WG Last Call based on this document, with the expiry two weeks
    >hence (24 December).
    >
    >Changes from the previous version are as follows:
    >
    >- removed reqt 5.6 c) Support general test capabilities, for example
    >loopbacks through the MG to test DSP operation.
    >It was agreed that inward loopbacks are outside the scope of the protocol
    >- they are not part of call control, so would be handled by some other
    >maintenance protocol. Thus the above requirement is deleted.
    >
    >- reqt 5.7 a) - changed word call to connection
    >
    >- table in section 11 - removed  wiretap
    >
    >- reqt 11.1.3.1 a) rewording of 2nd bullet  on addressing - didn't mean
    >wildcarding, meant instead allowing the gateway to choose (part of) the
    >identifier
    >
    >The references need to be completed still, and there may be an editor's
    >note or two that should still come out.
    >-----Original Message-----  From:   Internet-Drafts@IETF.ORG
    >[SMTP:Internet-Drafts@IETF.ORG]  Sent:   Friday, December 10, 1999 8:08
    >AM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:        I-D
    >ACTION:draft-ietf-megaco-reqs-09.txt
    >
    >A New Internet-Draft is available from the on-line Internet-Drafts
    >directories.  This draft is a work item of the Media Gateway Control
    >Working Group of the IETF.
    >
    >         Title           : Media Gateway control protocol architecture
    > and                            requirements          Author(s)       : N.
    > Greene,  M. Ramalho,  B. Rosen          Filename        :
    > draft-ietf-megaco-reqs-09.txt          Pages           :
    > 45          Date            : 09-Dec-99
    >
    >TThis document describes protocol requirements for the Media Gateway
    >control protocol between a Media Gateway Controller and a Media Gateway. A
    >URL for this Internet-Draft
    >is:
    ><http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>http://w
    >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt
    >
    >Internet-Drafts are also available by anonymous FTP. Login with the
    >username  "anonymous" and a password of your e-mail address. After logging
    >in,  type "cd internet-drafts" and then          "get
    >draft-ietf-megaco-reqs-09.txt".
    >
    >A list of Internet-Drafts directories can be found
    >in  <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html  or
    ><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-
    >sites.txt
    >
    >Internet-Drafts can also be obtained by e-mail.
    >
    >Send a message to:          mailserv@ietf.org.  In the body
    >type:          "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt".
    >
    >NOTE:   The mail server at ietf.org can return the document
    >in          MIME-encoded form by using the "mpack" utility.  To use
    >this          feature, insert the command "ENCODING mime" before the
    >"FILE"          command.  To decode the response(s), you will need
    >"munpack" or          a MIME-compliant mail reader.  Different
    >MIME-compliant mail readers          exhibit different behavior,
    >especially when dealing with          "multipart" MIME messages (i.e.
    >documents which have been split          up into multiple messages), so
    >check your local documentation on          how to manipulate these messages.
    >
    >Below is the data which will enable a MIME compliant mail
    >reader  implementation to automatically retrieve the ASCII version of
    >the  Internet-Draft. << Message:  >>

--------------031590B9E580AC7625158ACA-- --------------37E667F8FF22ADA5DCF4134F Content-Type: text/x-vcard; charset=us-ascii; name="goutam.shaw.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Goutam Shaw Content-Disposition: attachment; filename="goutam.shaw.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Shaw;Goutam x-mozilla-html:FALSE org:Bridgewater Systems Corp. adr:;;800-555 Legget Dr.;Ottawa;Ontario;K1G5J7;Canada version:2.1 email;internet:goutam.shaw@bridgewatersys.com title:Product Manager tel;fax:613-591-6656 tel;work:613-591-6655 x2796 x-mozilla-cpt:;0 fn:Goutam Shaw end:vcard --------------37E667F8FF22ADA5DCF4134F-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 18:46:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15201 for ; Mon, 10 Jan 2000 18:46:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6B561230@standards.nortelnetworks.com>; Mon, 10 Jan 2000 18:35:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116492 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 18:33:26 -0500 Received: from igw1.ericsson.com.au by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C850C8B0@standards.nortelnetworks.com>; Mon, 10 Jan 2000 18:23:24 -0500 Received: from brfw1 (igw2.ericsson.com.au [203.61.155.10]) by igw1.ericsson.com.au (8.9.1b+Sun/8.9.1) with SMTP id KAA29247; Tue, 11 Jan 2000 10:24:38 +1100 (EST) Received: from brsi02 ([146.11.15.8]) by brfw1.ericsson.com.au; Tue, 11 Jan 2000 10:21:24 +0000 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA17181; Tue, 11 Jan 2000 10:25:23 +1100 (EST) Received: from ericsson.com (mc2dh10.epa.ericsson.se [146.11.87.10]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.1) with ESMTP id KAA21186; Tue, 11 Jan 2000 10:23:28 +1100 (EST) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387AF4AA.1FF9EA83@ericsson.com> Date: Tue, 11 Jan 2000 10:15:22 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Proposed Text For Media Specification X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I support the introduction of parameters for 'choose' or 'reserveALL' to support Fast Connect. Would another alternative to Local Control to be to add it to the command syntax as 'choose' or 'reserve' would be related to commands? ie. ADD(Ctxt1),T1,[reserve+choose],Local[P1=v1,p2=v2],Remote[p3=v3,p4=v4] Cheers, Christian Tom-PT Taylor wrote: > > Unfortunately this doesn't seem to be quite the last word. From > H.323v2 section 8.1.7 "Fast Connect Procedure", here is how fast > connect works. > > > > "The calling endpoint initiates the Fast Connect procedure by sending > a SETUP message containing the > fastStart element to the called endpoint. The fastStart element > consists of a sequence of > OpenLogicalChannel structures describing media channels which the > calling endpoint proposes to send > and receive, including all of the parameters necessary to immediately > open and begin transferring > media on the channels. Details of the content and usage of the > fastStart element are discussed below. > ... > "The called endpoint may begin transmitting media (according to the > channels opened) immediately > after sending a Q.931 message containing fastStart. The calling > endpoint must therefore be prepared > to receive media on any of the receive channels it proposed in the > SETUP message, since it is possible > for the media to be received prior to the Q.931 message indicating > precisely which channels will be > used. Once a Q.931 message containing fastStart is received by the > calling endpoint, the calling > endpoint may discontinue attempting to receive media on the channels > for which proposals were not > accepted by the called endpoint. Note that national requirements may > prohibit called endpoints from > transmitting media, or limit the nature of the content of the media > stream, prior to transmission of a > CONNECT message; it is the responsibility of the endpoint to comply > with applicable requirements. If > the calling endpoint sets the mediaWaitForConnect element to TRUE in > the SETUP message, then the > called endpoint shall not send any media until after the CONNECT > message is sent." > > > > Note particularly that the originating end has to reserve resources > for both the send and receive directions of flow. This issue here is > that the originating end may want to reserve alternatives, leaving the > far end to choose from amongst them. This implies a non-empty Remote > Descriptor, which according to the rules stated below would cause the > originating MG to select a single alternative rather than reserve > resources for everything proposed. > > The answer probably lies in adding a parameter to LocalControl, with > the two values "choose" or "reserveAll". If "choose" is specified the > rules below are applied. Otherwise the MG reserves resources as > specified in Local and Remote according to the listed order of > preference, and is prepared to receive any flow listed in Local > immediately upon responding to the MGC. > > One more issue here: what to fill in for the far-end address in > Remote, pending a response from the far end? I proposed using dashes > earlier, but how about following a convention used in SIP and > supplying an address consisting of all zeroes? > > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Wednesday, January 05, 2000 11:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > I think your first alternative looks reasonable. If I may, I'll > restate what you've said with a little amplification, as follows: > > "When the MG receives a non-empty Remote Descriptor containing > multiple session descriptions, it must choose which of these > descriptions it will support and indicate its choice in its > response to the MGC. It makes this choice according to the > following logic: > > (1) If the MGC did not provide a Local Descriptor in the command > and no resources were reserved for media reception by a previous > command, then the MG assumes that the stream will be send-only. > It selects the first session description in Remote that it > supports. > > (2) If the MGC did not provide a Local Descriptor in the command, > but reserved resources by setting Local in a previous command, > then the MG compares the reserved resources against Remote and > chooses according to the following principles: > > (a) If possible, the MG establishes a symmetric media flow, with > the same encoding for both directions. > > (b) If multiple choices for symmetric media flows are available, > it chooses the one most preferred by the MGC as previously set in > Local. > > (c) If symmetric encoding is not possible, it chooses the first > session description in Remote that it supports, and returns that > along with the complete list of session descriptions in Local for > which it has reserved resources. > > (3) If the MGC provided an empty Local Descriptor in the command > what happens? According to our previous correspondence, it's > something like this: the MG chooses the first session > description in Remote that it supports, but returns in Local all > of the possibilities for which it was able to reserve resources, > given the selection in Remote. > > (4) If the MGC provided a non-empty Local Descriptor, then the MG > applies the principles listed in (2) to make a unique choice for > both Local and Remote. > > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Tuesday, January 04, 2000 9:43 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: Michael Thomas; megaco@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > Tom-PT Taylor writes: > > In your second case in step (4), why doesn't the MG converge > on the single > > selection s3 for Local and Remote? How does it know that it > should leave > > Local unresolved? > > You're right. There are two choices: > > 1) If we want to modify my description that the > MG should at each Local descriptor in order > and for each descriptor it can accommodate, > it should then look into the choices in the > Remote descriptor. If it finds a matching > descriptor, it should select that SDP alone > for both Remote and Local, otherwise it > keeps checking the choices within Local > against Remote until a match if found, or > Local is exhausted. If Local is exhaused, > MGt should return the Local descriptors > it can accommodate, along with the most > prefereable descriptor in Remote. > > The advantage here is that it preserves MGC > priorities while still converging on a symmetric > codec in a 3-way handshake. > > 2) We could leave it the way I have it, for > which it would choose s3. If so, would > you like me to contrive an example which > actually does the negotiation right? > > Mike > > > > > > > -----Original Message----- > > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > > Sent: Tuesday, January 04, 2000 11:57 AM > > [[TomT]] First case snipped. > > > > > For *asynchronous* negotiation we modify the flow > > > slightly: > > > > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > > > MGC sends initial add to the originator; remote > > > unknown. Local choice are policy > > > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > > > MGo chooses s1 and s3; can't do s2 because of > > > resources > > > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > > > MGC adds MGt, sets policy in local, sends > > > choices in remote from MGo; note MGC sends > > > policy of not using s1 (for whatever reason) > > > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > > > MGt firstly notices that Remote has choices. It > > > then SHOULD take the intersection of Local and > > > Remote's choices and return the most preferable > > > choice (ie, first in list). If there is not an > > > intersection, MG MUST choose one in Remote and > > > send back the choices in Local that it can > > > accommodate (s2, s3). > > > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > > > MGC modifies MGo with the choices. Note Remote > > > is not fully qualified. The MGC MUST at this > > > point remember that it needs to do a 4 way > > > handshake since it saw choices in remote going > > > to MGo > > > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > > > MGo acks the Modify, and chooses s3 because it > > > still cannot do s2 in remote > > > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > > > MGC transmits the final choices to MGt > > > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > > > MGt acks the modify and we're going. > > > > > > Mike > > > > > > Rosen, Brian writes: > > > > I think buffering is going to be needed if you are > encrypting. > > > > The real question is whether you always have to do this, > or there > > > > is some way to know if you might be. > > > > > > > > The syntax problem is pretty much a "local" thing. On > the originating > > > end, > > > > you want to ask for capability. On the terminating end, > you want to > > > ask the > > > > MG to make a choice. In both cases, it's local that this > happens in. > > > The > > > > other end gets the result (the return from the add) as > its remote. > > > > > > > > The following is more detail than you need, but I thought > I'd > > > > write down how I think it works in great detail for > others > > > > to decide if they agree, or have a different view: > > > > > > > > More specifically, the originating end gets the > terminating > > > > end's local as its remote, while the terminating end gets > a > > > > negotiated version of the originating end's local as its > remote). > > > > Working this out a little more, the originating MGC, > having no idea > > > what the > > > > terminating side wants, has only its local policy. It > puts this in > > > local in > > > > the first Add. The originating MG filters this (takes > out what it > > > can't > > > > do), reserving worst case resources, and > > > > returns this filtered version of local in the response to > the Add. > > > > There is no remote at all in this Add, because the > originating MGC > > > > doesn't know any part of what goes in remote. > > > > > > > > The originating MGC sends this to the terminating MGC. > The terminating > > > MG > > > > filters the received proposal with its policy, > > > > and sends it in remote. If it will allow asymmetric > coding (unusual) > > > > it could just send its policy in local, but in most > cases, it will > > > > just present the same coding options it got from the > originating > > > > end, filtered by it's policy (which could be reordering, > as well > > > > as removing options) in local. > > > > > > > > The terminating MG gets the choices and chooses one for > local and > > > > remote (usually the same, could be different) if it can > and returns > > > > the single chosen value in the reply to its add. If it > cannot, > > > > it means none of the offered choices are acceptable. In > that case > > > > it must return an error. The response to this error > might be > > > > to attempt the Add again with just the terminating end's > policy, > > > > which would be returned, and then the terminating end can > propose > > > > those choices in a full (non fast start) negotiation. > > > > Assuming success, the terminating MGC returns the choice > to the > > > originating > > > > MGC, which modifies the termination, both in local and > > > > remote. > > > > > > > > As with the prior discussion, this means local has what > you send, > > > > and remote has what you receive (which is what the other > end sends). > > > > > > > > You see the syntax issue in local? The originating MG > sees an > > > > Add with an overspecified local, but returns an > overspecified local. > > > > The terminating MG sees an Add with an overspecified > local but > > > > returns a fully specified local. The originating MG > doesn't get > > > > a remote with the add. The terminating MG sees an > overspecified remote > > > > which it returns fully specified. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Michael Thomas [ ] > > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > Rosen, Brian writes: > > > > > > If true, it means if you see media before the > modify, then you > > > > > > start decoding, and if the modify says something > different than > > > > > > you implied from the header, it's an error. It > isn't necessary to > > > > > > wait until you get the modify before you can process > the media. > > > > > > I suppose that since there is the possibility of > asymmetric > > > coding, > > > > > > you can't send any media until you have the modify. > > > > > > > > > > That's what I was afraid of. This implies that > either > > > > > you load all of the proposed codecs (not just > > > > > account for their maximum MIPS and ram as you > > > > > implied), or you better be able to load the > > > > > codec PDQ once you see the first media packet. > > > > > > > > > > A worse problem is if you want to negotiate > > > > > cipher suites with payload encryption. There, > > > > > unless cipher suite negotiation is tied to the > > > > > type field somehow (it is not in packetcable, > > > > > as one data point), you have no clue how the > > > > > packet is encrypted, which effectively causes > > > > > front end clipping too. > > > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > > necessity, maybe the right thing to do would be > > > > > to buffer the packets in the playback buffer > > > > > and not process them until the last Modify > > > > > came in -- this gives the whole playback > > > > > delay for the arrival of the Modify before you > > > > > had to drop the packets on the head of the > > > > > queue. > > > > > > > > > > > HOWEVER, this means we need syntax to differentiate > between an > > > > > > add with policy, respond with capability, and add > with policy, > > > > > > choose one and respond with your choice. > > > > > > > > > > Isn't this where Local and Remote come into > > > > > play? If I see several choices in Remote (eg > > > > > the other side's local), isn't that the trigger > > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > > > Mike > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Michael Thomas [ ] > > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > > I'm willing to follow this thought along a bit > further. I > > > > > > > think the > > > > > > > > concrete difference between the viewpoint I've > > > > > documented and the > > > > > > > > "policy-capability" viewpoint is this: if the > MGC sends > > > > > > > down a number of > > > > > > > > alternative session descriptions, in my case > the MG picks > > > > > > > one, while in > > > > > > > > Brian's case the MG replies with all the > session > > > > > > > descriptions it can > > > > > > > > currently support. I am willing to accept the > latter > > > > > > > proposition if we can > > > > > > > > all agree on it. From there, I will go forward > with > > > > > > > Chip's distinction > > > > > > > > between the roles of Local and Remote, and I > think we'll > > > > > > > have a good > > > > > > > > sensible result. > > > > > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > > > syntax when you could use SDP to do the same, > > > > > > > there are three constraints which we must > adhere > > > > > > > to: > > > > > > > > > > > > > > 1) Negotiation must happen with a three way > handshake > > > > > > > between the MGC and the two MG's: eg > > > > > Add(o)/Add(t)/Modify(o) > > > > > > > I think that Tom's original proposal does > not meet this > > > > > > > requirement, though Brian's does. > > > > > > > > > > > > > > 2) MG's which offer the set of codec > alternatives in > > > > > > > Brian's proposal MUST NOT be expected to > have those > > > > > > > coders actually loaded and prepared to > process media > > > > > > > packets. The MG will only prepare itself for > receipt > > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > > > 3) The entire process MUST NOT lead to front > end clipping. > > > > > > > I'm not sure how you do this given the other > constraints > > > > > > > other than making it into a 4 way handshake. > Maybe > > > somebody > > > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > >

In your second > case in step (4), why doesn't the MG converge on the single > selection s3 for Local and Remote?  How does it know that it > should leave Local unresolved?

> > >
    > >

    -----Original Message----- > >
    From:   > Michael Thomas > [SMTP:mat@CISCO.COM] > > >
    FACE="Arial">Sent:   FACE="Arial">Tuesday, January 04, 2000 11:57 AM > > >
    FACE="Arial">[[TomT]]  COLOR="#0000FF" SIZE=2 FACE="Arial"> First case > snipped. FACE="Arial"> > > >

    > > > >

    For *asynchronous* negotiation we > modify the flow > >
    slightly: > >

    > >
    > > > >

    1) MGC->MGo: Add { Local { s1, > s2, s3} Remote {}} > >

    > > > >

       MGC sends initial > add to the originator; remote > >
       unknown. Local > choice are policy > >

    > > > >

    2) MGo->MGC: Add = { Local { > s1, s3} Remote {}} > >

    > > > >

       MGo chooses s1 and > s3; can't do s2 because of > >
       resources > >

    > > > >

    3) MGC->MGt: Add { Local { s2, > s3} Remote { s1, s3}} > >

    > > > >

       MGC adds MGt, sets > policy in local, sends > >
       choices in remote > from MGo; note MGC sends > >
       policy of not using > s1 (for whatever reason) > >

    > > > >

    4) MGt->MGC: Add = { Local { > s2, s3 } Remote {s1}} > >

    > > > >

       MGt firstly notices > that Remote has choices. It > >
       then SHOULD take > the intersection of Local and > >
       Remote's choices > and return the most preferable > >
       choice (ie, first > in list). If there is not an > >
       intersection, MG > MUST choose one in Remote and > >
       send back the > choices in Local that it can > >
       accommodate (s2, > s3). > >

    > > > >

    5) MGC->MGo: Modify { Local { > s1 } Remote { s2, s3 }} > >

    > > > >

       MGC modifies MGo > with the choices. Note Remote > >
       is not fully > qualified. The MGC MUST at this > >
       point remember that > it needs to do a 4 way > >
       handshake since it > saw choices in remote going > >
       to MGo > >

    > > > >

    6) MGo->MGC: Modify = { Local > { s1 } Remote { s3}} > >

    > > > >

       MGo acks the Modify, > and chooses s3 because it > >
       still cannot do s2 > in remote > >

    > > > >

    7) MGC->MGt: Modify { Local { > s3 } Remote { s1 }} > >

    > > > >

       MGC transmits the > final  choices to MGt > >

    > > > >

    8) MGt->MGC: Modify = { Local > { s3 } Remote { s1}} > >

    > > > >

       MGt acks the modify > and we're going. > >

    > > > >

    FACE="Arial">            > Mike > >

    > > > >

    Rosen, Brian writes: > >
     > I think buffering is > going to be needed if you are encrypting. > >
     > The real question is > whether you always have to do this, or there > >
     > is some way to know > if you might be. > >
     > > >
     > The syntax problem is > pretty much a "local" thing.  On the originating > end, > > >
     > you want to > ask for capability.  On the terminating end, you want to ask > the > > >
     > MG to make a > choice.  In both cases, it's local that this happens > in.  The > > >
     > other end > gets the result (the return from the add) as its remote. > >
     > > >
     > The following is more > detail than you need, but I thought I'd > >
     > write down how I > think it works in great detail for others > >
     > to decide if they > agree, or have a different view: > >
     > > >
     > More specifically, > the originating end gets the terminating > >
     > end's local as its > remote, while the terminating end gets a > >
     > negotiated version of > the originating end's local as its remote). > >
     > Working this out a > little more, the originating MGC, having no idea what the > > >
     > terminating > side wants, has only its local policy. It puts this in local > in > > >
     > the first > Add.  The originating MG filters this (takes out what it > can't > > >
     > do), > reserving worst case resources, and > >
     > returns this filtered > version of local in the response to the Add. > >
     > There is no remote at > all in this Add, because the originating MGC > >
     > doesn't know any part > of what goes in remote. > >
     > > >
     > The originating MGC > sends this to the terminating MGC.  The terminating > MG > > >
     > filters the > received proposal with its policy, > >
     > and sends it in > remote.  If it will allow asymmetric coding (unusual) > > >
     > it could just > send its policy in local, but in most cases, it will > >
     > just present the same > coding options it got from the originating > >
     > end, filtered by it's > policy (which could be reordering, as well > >
     > as removing options) > in local. > >
     > > >
     > The terminating MG > gets the choices and chooses one for local and > >
     > remote (usually the > same, could be different) if it can and returns > >
     > the single chosen > value in the reply to its add.  If it cannot, > >
     > it means none of the > offered choices are acceptable.  In that case > > >
     > it must > return an error.  The response to this error might be > >
     > to attempt the Add > again with just the terminating end's policy, > >
     > which would be > returned, and then the terminating end can propose > >
     > those choices in a > full (non fast start) negotiation. > >
     > Assuming success, the > terminating MGC returns the choice to the originating > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 20:57:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16144 for ; Mon, 10 Jan 2000 20:57:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B212880@standards.nortelnetworks.com>; Mon, 10 Jan 2000 20:45:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116640 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 20:44:08 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.70394580@standards.nortelnetworks.com>; Mon, 10 Jan 2000 20:44:07 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 10 Jan 2000 19:54:24 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 10 Jan 2000 20:53:58 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 20:53:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5BD6.B8C3E2BC" Message-ID: Date: Mon, 10 Jan 2000 20:53:55 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5BD6.B8C3E2BC Content-Type: text/plain; charset="iso-8859-1" I prefer LocalControl because that gives you per-stream control. That may be useful to allow previously-established streams to remain undisturbed if H.245 is used to negotiate new ones. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Tuesday, January 11, 2000 4:15 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed Text For Media Specification > > G'Day Tom, > > I support the introduction of parameters for 'choose' or 'reserveALL' to > support Fast Connect. > > Would another alternative to Local Control to be to add it to the > command syntax as 'choose' or 'reserve' would be related to commands? > ie. > ADD(Ctxt1),T1,[reserve+choose],Local[P1=v1,p2=v2],Remote[p3=v3,p4=v4] > > Cheers, Christian > > Tom-PT Taylor wrote: > > > > Unfortunately this doesn't seem to be quite the last word. From > > H.323v2 section 8.1.7 "Fast Connect Procedure", here is how fast > > connect works. > > > > > > > > "The calling endpoint initiates the Fast Connect procedure by sending > > a SETUP message containing the > > fastStart element to the called endpoint. The fastStart element > > consists of a sequence of > > OpenLogicalChannel structures describing media channels which the > > calling endpoint proposes to send > > and receive, including all of the parameters necessary to immediately > > open and begin transferring > > media on the channels. Details of the content and usage of the > > fastStart element are discussed below. > > ... > > "The called endpoint may begin transmitting media (according to the > > channels opened) immediately > > after sending a Q.931 message containing fastStart. The calling > > endpoint must therefore be prepared > > to receive media on any of the receive channels it proposed in the > > SETUP message, since it is possible > > for the media to be received prior to the Q.931 message indicating > > precisely which channels will be > > used. Once a Q.931 message containing fastStart is received by the > > calling endpoint, the calling > > endpoint may discontinue attempting to receive media on the channels > > for which proposals were not > > accepted by the called endpoint. Note that national requirements may > > prohibit called endpoints from > > transmitting media, or limit the nature of the content of the media > > stream, prior to transmission of a > > CONNECT message; it is the responsibility of the endpoint to comply > > with applicable requirements. If > > the calling endpoint sets the mediaWaitForConnect element to TRUE in > > the SETUP message, then the > > called endpoint shall not send any media until after the CONNECT > > message is sent." > > > > > > > > Note particularly that the originating end has to reserve resources > > for both the send and receive directions of flow. This issue here is > > that the originating end may want to reserve alternatives, leaving the > > far end to choose from amongst them. This implies a non-empty Remote > > Descriptor, which according to the rules stated below would cause the > > originating MG to select a single alternative rather than reserve > > resources for everything proposed. > > > > The answer probably lies in adding a parameter to LocalControl, with > > the two values "choose" or "reserveAll". If "choose" is specified the > > rules below are applied. Otherwise the MG reserves resources as > > specified in Local and Remote according to the listed order of > > preference, and is prepared to receive any flow listed in Local > > immediately upon responding to the MGC. > > > > One more issue here: what to fill in for the far-end address in > > Remote, pending a response from the far end? I proposed using dashes > > earlier, but how about following a convention used in SIP and > > supplying an address consisting of all zeroes? > > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > Sent: Wednesday, January 05, 2000 11:23 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Proposed Text For Media Specification > > > > I think your first alternative looks reasonable. If I may, I'll > > restate what you've said with a little amplification, as follows: > > > > "When the MG receives a non-empty Remote Descriptor containing > > multiple session descriptions, it must choose which of these > > descriptions it will support and indicate its choice in its > > response to the MGC. It makes this choice according to the > > following logic: > > > > (1) If the MGC did not provide a Local Descriptor in the command > > and no resources were reserved for media reception by a previous > > command, then the MG assumes that the stream will be send-only. > > It selects the first session description in Remote that it > > supports. > > > > (2) If the MGC did not provide a Local Descriptor in the command, > > but reserved resources by setting Local in a previous command, > > then the MG compares the reserved resources against Remote and > > chooses according to the following principles: > > > > (a) If possible, the MG establishes a symmetric media flow, with > > the same encoding for both directions. > > > > (b) If multiple choices for symmetric media flows are available, > > it chooses the one most preferred by the MGC as previously set in > > Local. > > > > (c) If symmetric encoding is not possible, it chooses the first > > session description in Remote that it supports, and returns that > > along with the complete list of session descriptions in Local for > > which it has reserved resources. > > > > (3) If the MGC provided an empty Local Descriptor in the command > > what happens? According to our previous correspondence, it's > > something like this: the MG chooses the first session > > description in Remote that it supports, but returns in Local all > > of the possibilities for which it was able to reserve resources, > > given the selection in Remote. > > > > (4) If the MGC provided a non-empty Local Descriptor, then the MG > > applies the principles listed in (2) to make a unique choice for > > both Local and Remote. > > > > -----Original Message----- > > From: Michael Thomas [SMTP:mat@cisco.com] > > Sent: Tuesday, January 04, 2000 9:43 PM > > To: Taylor, Tom-PT [CAR:B904:EXCH] > > Cc: Michael Thomas; megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > Tom-PT Taylor writes: > > > In your second case in step (4), why doesn't the MG converge > > on the single > > > selection s3 for Local and Remote? How does it know that it > > should leave > > > Local unresolved? > > > > You're right. There are two choices: > > > > 1) If we want to modify my description that the > > MG should at each Local descriptor in order > > and for each descriptor it can accommodate, > > it should then look into the choices in the > > Remote descriptor. If it finds a matching > > descriptor, it should select that SDP alone > > for both Remote and Local, otherwise it > > keeps checking the choices within Local > > against Remote until a match if found, or > > Local is exhausted. If Local is exhaused, > > MGt should return the Local descriptors > > it can accommodate, along with the most > > prefereable descriptor in Remote. > > > > The advantage here is that it preserves MGC > > priorities while still converging on a symmetric > > codec in a 3-way handshake. > > > > 2) We could leave it the way I have it, for > > which it would choose s3. If so, would > > you like me to contrive an example which > > actually does the negotiation right? > > > > Mike > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > > > Sent: Tuesday, January 04, 2000 11:57 AM > > > [[TomT]] First case snipped. > > > > > > > For *asynchronous* negotiation we modify the flow > > > > slightly: > > > > > > > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > > > > > MGC sends initial add to the originator; remote > > > > unknown. Local choice are policy > > > > > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > > > > > MGo chooses s1 and s3; can't do s2 because of > > > > resources > > > > > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > > > > > MGC adds MGt, sets policy in local, sends > > > > choices in remote from MGo; note MGC sends > > > > policy of not using s1 (for whatever reason) > > > > > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > > > > > MGt firstly notices that Remote has choices. It > > > > then SHOULD take the intersection of Local and > > > > Remote's choices and return the most preferable > > > > choice (ie, first in list). If there is not an > > > > intersection, MG MUST choose one in Remote and > > > > send back the choices in Local that it can > > > > accommodate (s2, s3). > > > > > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > > > > > MGC modifies MGo with the choices. Note Remote > > > > is not fully qualified. The MGC MUST at this > > > > point remember that it needs to do a 4 way > > > > handshake since it saw choices in remote going > > > > to MGo > > > > > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > > > > > MGo acks the Modify, and chooses s3 because it > > > > still cannot do s2 in remote > > > > > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > > > > > MGC transmits the final choices to MGt > > > > > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > > > > > MGt acks the modify and we're going. > > > > > > > > Mike > > > > > > > > Rosen, Brian writes: > > > > > I think buffering is going to be needed if you are > > encrypting. > > > > > The real question is whether you always have to do this, > > or there > > > > > is some way to know if you might be. > > > > > > > > > > The syntax problem is pretty much a "local" thing. On > > the originating > > > > end, > > > > > you want to ask for capability. On the terminating end, > > you want to > > > > ask the > > > > > MG to make a choice. In both cases, it's local that this > > happens in. > > > > The > > > > > other end gets the result (the return from the add) as > > its remote. > > > > > > > > > > The following is more detail than you need, but I thought > > I'd > > > > > write down how I think it works in great detail for > > others > > > > > to decide if they agree, or have a different view: > > > > > > > > > > More specifically, the originating end gets the > > terminating > > > > > end's local as its remote, while the terminating end gets > > a > > > > > negotiated version of the originating end's local as its > > remote). > > > > > Working this out a little more, the originating MGC, > > having no idea > > > > what the > > > > > terminating side wants, has only its local policy. It > > puts this in > > > > local in > > > > > the first Add. The originating MG filters this (takes > > out what it > > > > can't > > > > > do), reserving worst case resources, and > > > > > returns this filtered version of local in the response to > > the Add. > > > > > There is no remote at all in this Add, because the > > originating MGC > > > > > doesn't know any part of what goes in remote. > > > > > > > > > > The originating MGC sends this to the terminating MGC. > > The terminating > > > > MG > > > > > filters the received proposal with its policy, > > > > > and sends it in remote. If it will allow asymmetric > > coding (unusual) > > > > > it could just send its policy in local, but in most > > cases, it will > > > > > just present the same coding options it got from the > > originating > > > > > end, filtered by it's policy (which could be reordering, > > as well > > > > > as removing options) in local. > > > > > > > > > > The terminating MG gets the choices and chooses one for > > local and > > > > > remote (usually the same, could be different) if it can > > and returns > > > > > the single chosen value in the reply to its add. If it > > cannot, > > > > > it means none of the offered choices are acceptable. In > > that case > > > > > it must return an error. The response to this error > > might be > > > > > to attempt the Add again with just the terminating end's > > policy, > > > > > which would be returned, and then the terminating end can > > propose > > > > > those choices in a full (non fast start) negotiation. > > > > > Assuming success, the terminating MGC returns the choice > > to the > > > > originating > > > > > MGC, which modifies the termination, both in local and > > > > > remote. > > > > > > > > > > As with the prior discussion, this means local has what > > you send, > > > > > and remote has what you receive (which is what the other > > end sends). > > > > > > > > > > You see the syntax issue in local? The originating MG > > sees an > > > > > Add with an overspecified local, but returns an > > overspecified local. > > > > > The terminating MG sees an Add with an overspecified > > local but > > > > > returns a fully specified local. The originating MG > > doesn't get > > > > > a remote with the add. The terminating MG sees an > > overspecified remote > > > > > which it returns fully specified. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [ ] > > > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > > > To: Rosen, Brian > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > Rosen, Brian writes: > > > > > > > If true, it means if you see media before the > > modify, then you > > > > > > > start decoding, and if the modify says something > > different than > > > > > > > you implied from the header, it's an error. It > > isn't necessary to > > > > > > > wait until you get the modify before you can process > > the media. > > > > > > > I suppose that since there is the possibility of > > asymmetric > > > > coding, > > > > > > > you can't send any media until you have the modify. > > > > > > > > > > > > That's what I was afraid of. This implies that > > either > > > > > > you load all of the proposed codecs (not just > > > > > > account for their maximum MIPS and ram as you > > > > > > implied), or you better be able to load the > > > > > > codec PDQ once you see the first media packet. > > > > > > > > > > > > A worse problem is if you want to negotiate > > > > > > cipher suites with payload encryption. There, > > > > > > unless cipher suite negotiation is tied to the > > > > > > type field somehow (it is not in packetcable, > > > > > > as one data point), you have no clue how the > > > > > > packet is encrypted, which effectively causes > > > > > > front end clipping too. > > > > > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > > > necessity, maybe the right thing to do would be > > > > > > to buffer the packets in the playback buffer > > > > > > and not process them until the last Modify > > > > > > came in -- this gives the whole playback > > > > > > delay for the arrival of the Modify before you > > > > > > had to drop the packets on the head of the > > > > > > queue. > > > > > > > > > > > > > HOWEVER, this means we need syntax to differentiate > > between an > > > > > > > add with policy, respond with capability, and add > > with policy, > > > > > > > choose one and respond with your choice. > > > > > > > > > > > > Isn't this where Local and Remote come into > > > > > > play? If I see several choices in Remote (eg > > > > > > the other side's local), isn't that the trigger > > > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Thomas [ ] > > > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > > > I'm willing to follow this thought along a bit > > further. I > > > > > > > > think the > > > > > > > > > concrete difference between the viewpoint I've > > > > > > documented and the > > > > > > > > > "policy-capability" viewpoint is this: if the > > MGC sends > > > > > > > > down a number of > > > > > > > > > alternative session descriptions, in my case > > the MG picks > > > > > > > > one, while in > > > > > > > > > Brian's case the MG replies with all the > > session > > > > > > > > descriptions it can > > > > > > > > > currently support. I am willing to accept the > > latter > > > > > > > > proposition if we can > > > > > > > > > all agree on it. From there, I will go forward > > with > > > > > > > > Chip's distinction > > > > > > > > > between the roles of Local and Remote, and I > > think we'll > > > > > > > > have a good > > > > > > > > > sensible result. > > > > > > > > > > > > > > > > Aside from the issue of not wanting to recreate > > > > > > > > syntax when you could use SDP to do the same, > > > > > > > > there are three constraints which we must > > adhere > > > > > > > > to: > > > > > > > > > > > > > > > > 1) Negotiation must happen with a three way > > handshake > > > > > > > > between the MGC and the two MG's: eg > > > > > > Add(o)/Add(t)/Modify(o) > > > > > > > > I think that Tom's original proposal does > > not meet this > > > > > > > > requirement, though Brian's does. > > > > > > > > > > > > > > > > 2) MG's which offer the set of codec > > alternatives in > > > > > > > > Brian's proposal MUST NOT be expected to > > have those > > > > > > > > coders actually loaded and prepared to > > process media > > > > > > > > packets. The MG will only prepare itself for > > receipt > > > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > > > > > 3) The entire process MUST NOT lead to front > > end clipping. > > > > > > > > I'm not sure how you do this given the other > > constraints > > > > > > > > other than making it into a 4 way handshake. > > Maybe > > > > somebody > > > > > > > > more clever than me can solve that problem. > > > > > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > > > > > >

    In your second > > case in step (4), why doesn't the MG converge on the single > > selection s3 for Local and Remote?  How does it know that it > > should leave Local unresolved?

    > > > > >
      > > >

      -----Original Message----- > > >
      From:   > > Michael Thomas > > [SMTP:mat@CISCO.COM] > > > > >
      > FACE="Arial">Sent:   > FACE="Arial">Tuesday, January 04, 2000 11:57 AM > > > > >
      > FACE="Arial">[[TomT]]  > COLOR="#0000FF" SIZE=2 FACE="Arial"> First case > > snipped. > FACE="Arial"> > > > > >

      > > > > > >

      For *asynchronous* negotiation we > > modify the flow > > >
      slightly: > > >

      > > >
      > > > > > >

      1) MGC->MGo: Add { Local { s1, > > s2, s3} Remote {}} > > >

      > > > > > >

         MGC sends initial > > add to the originator; remote > > >
         unknown. Local > > choice are policy > > >

      > > > > > >

      2) MGo->MGC: Add = { Local { > > s1, s3} Remote {}} > > >

      > > > > > >

         MGo chooses s1 and > > s3; can't do s2 because of > > >
         resources > > >

      > > > > > >

      3) MGC->MGt: Add { Local { s2, > > s3} Remote { s1, s3}} > > >

      > > > > > >

         MGC adds MGt, sets > > policy in local, sends > > >
         choices in remote > > from MGo; note MGC sends > > >
         policy of not using > > s1 (for whatever reason) > > >

      > > > > > >

      4) MGt->MGC: Add = { Local { > > s2, s3 } Remote {s1}} > > >

      > > > > > >

         MGt firstly notices > > that Remote has choices. It > > >
         then SHOULD take > > the intersection of Local and > > >
         Remote's choices > > and return the most preferable > > >
         choice (ie, first > > in list). If there is not an > > >
         intersection, MG > > MUST choose one in Remote and > > >
         send back the > > choices in Local that it can > > >
         accommodate (s2, > > s3). > > >

      > > > > > >

      5) MGC->MGo: Modify { Local { > > s1 } Remote { s2, s3 }} > > >

      > > > > > >

         MGC modifies MGo > > with the choices. Note Remote > > >
         is not fully > > qualified. The MGC MUST at this > > >
         point remember that > > it needs to do a 4 way > > >
         handshake since it > > saw choices in remote going > > >
         to MGo > > >

      > > > > > >

      6) MGo->MGC: Modify = { Local > > { s1 } Remote { s3}} > > >

      > > > > > >

         MGo acks the Modify, > > and chooses s3 because it > > >
         still cannot do s2 > > in remote > > >

      > > > > > >

      7) MGC->MGt: Modify { Local { > > s3 } Remote { s1 }} > > >

      > > > > > >

         MGC transmits the > > final  choices to MGt > > >

      > > > > > >

      8) MGt->MGC: Modify = { Local > > { s3 } Remote { s1}} > > >

      > > > > > >

         MGt acks the modify > > and we're going. > > >

      > > > > > >

      > > FACE="Arial">          & > nbsp; > > Mike > > >

      > > > > > >

      Rosen, Brian writes: > > >
       > I think buffering is > > going to be needed if you are encrypting. > > >
       > The real question is > > whether you always have to do this, or there > > >
       > is some way to know > > if you might be. > > >
       > > > >
       > The syntax problem is > > pretty much a "local" thing.  On the originating > > end, > > > > >
       > you want to > > ask for capability.  On the terminating end, you want to ask > > the > > > > >
       > MG to make a > > choice.  In both cases, it's local that this happens > > in.  The > > > > >
       > other end > > gets the result (the return from the add) as its remote. > > >
       > > > >
       > The following is more > > detail than you need, but I thought I'd > > >
       > write down how I > > think it works in great detail for others > > >
       > to decide if they > > agree, or have a different view: > > >
       > > > >
       > More specifically, > > the originating end gets the terminating > > >
       > end's local as its > > remote, while the terminating end gets a > > >
       > negotiated version of > > the originating end's local as its remote). > > >
       > Working this out a > > little more, the originating MGC, having no idea what the > > > > >
       > terminating > > side wants, has only its local policy. It puts this in local > > in > > > > >
       > the first > > Add.  The originating MG filters this (takes out what it > > can't > > > > >
       > do), > > reserving worst case resources, and > > >
       > returns this filtered > > version of local in the response to the Add. > > >
       > There is no remote at > > all in this Add, because the originating MGC > > >
       > doesn't know any part > > of what goes in remote. > > >
       > > > >
       > The originating MGC > > sends this to the terminating MGC.  The terminating > > MG > > > > >
       > filters the > > received proposal with its policy, > > >
       > and sends it in > > remote.  If it will allow asymmetric coding (unusual) > > > > >
       > it could just > > send its policy in local, but in most cases, it will > > >
       > just present the same > > coding options it got from the originating > > >
       > end, filtered by it's > > policy (which could be reordering, as well > > >
       > as removing options) > > in local. > > >
       > > > >
       > The terminating MG > > gets the choices and chooses one for local and > > >
       > remote (usually the > > same, could be different) if it can and returns > > >
       > the single chosen > > value in the reply to its add.  If it cannot, > > >
       > it means none of the > > offered choices are acceptable.  In that case > > > > >
       > it must > > return an error.  The response to this error might be > > >
       > to attempt the Add > > again with just the terminating end's policy, > > >
       > which would be > > returned, and then the terminating end can propose > > >
       > those choices in a > > full (non fast start) negotiation. > > >
       > Assuming success, the > > terminating MGC returns the choice to the originating > > > > ------_=_NextPart_001_01BF5BD6.B8C3E2BC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Proposed Text For Media Specification

      I prefer = LocalControl because that gives you per-stream control.  That may = be useful to allow previously-established streams to remain undisturbed = if H.245 is used to negotiate new ones.

        -----Original Message-----
        From:   Christian Groves = [SMTP:Christian.Groves@ERICSSON.COM]
        Sent:   Tuesday, January 11, 2000 4:15 AM
        To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
        Subject:       = Re: Proposed Text For Media = Specification

        G'Day Tom,

        I support the introduction of = parameters for 'choose' or 'reserveALL' to
        support Fast Connect.

        Would another alternative to Local = Control to be to add it to the
        command syntax as 'choose' or = 'reserve' would be related to commands?
        ie.
        ADD(Ctxt1),T1,[reserve+choose],Local[P1=3Dv1,p2=3Dv2],Rem= ote[p3=3Dv3,p4=3Dv4]

        Cheers, Christian

        Tom-PT Taylor wrote:
        >
        > Unfortunately this doesn't seem = to be quite the last word.  From
        > H.323v2 section 8.1.7 "Fast = Connect Procedure", here is how fast
        > connect works.
        >
        > <quote>
        >
        > "The calling endpoint = initiates the Fast Connect procedure by sending
        > a SETUP message containing = the
        > fastStart element to the called = endpoint. The fastStart element
        > consists of a sequence of
        > OpenLogicalChannel structures = describing media channels which the
        > calling endpoint proposes to = send
        > and receive, including all of = the parameters necessary to immediately
        > open and begin = transferring
        > media on the channels. Details = of the content and usage of the
        > fastStart element are discussed = below.
        > ...
        > "The called endpoint may = begin transmitting media (according to the
        > channels opened) = immediately
        > after sending a Q.931 message = containing fastStart. The calling
        > endpoint must therefore be = prepared
        > to receive media on any of the = receive channels it proposed in the
        > SETUP message, since it is = possible
        > for the media to be received = prior to the Q.931 message indicating
        > precisely which channels will = be
        > used. Once a Q.931 message = containing fastStart is received by the
        > calling endpoint, the = calling
        > endpoint may discontinue = attempting to receive media on the channels
        > for which proposals were = not
        > accepted by the called endpoint. = Note that national requirements may
        > prohibit called endpoints = from
        > transmitting media, or limit the = nature of the content of the media
        > stream, prior to transmission of = a
        > CONNECT message; it is the = responsibility of the endpoint to comply
        > with applicable requirements. = If
        > the calling endpoint sets the = mediaWaitForConnect element to TRUE in
        > the SETUP message, then = the
        > called endpoint shall not send = any media until after the CONNECT
        > message is sent."
        >
        > </quote>
        >
        > Note particularly that the = originating end has to reserve resources
        > for both the send and receive = directions of flow.  This issue here is
        > that the originating end may = want to reserve alternatives, leaving the
        > far end to choose from amongst = them.  This implies a non-empty Remote
        > Descriptor, which according to = the rules stated below would cause the
        > originating MG to select a = single alternative rather than reserve
        > resources for everything = proposed.
        >
        > The answer probably lies in = adding a parameter to LocalControl, with
        > the two values = "choose" or "reserveAll".  If = "choose" is specified the
        > rules below are applied.  = Otherwise the MG reserves resources as
        > specified in Local and Remote = according to the listed order of
        > preference, and is prepared to = receive any flow listed in Local
        > immediately upon responding to = the MGC.
        >
        > One more issue here:  what = to fill in for the far-end address in
        > Remote, pending a response from = the far end?  I proposed using dashes
        > earlier, but how about following = a convention used in SIP and
        > supplying an address consisting = of all zeroes?
        >
        >      = -----Original Message-----
        >      = From:   Taylor, Tom-PT [CAR:B904:EXCH]
        >      = Sent:   Wednesday, January 05, 2000 11:23 AM
        >      = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
        >      = Subject:        Re: Proposed Text = For Media Specification
        >
        >      I = think your first alternative looks reasonable.  If I may, = I'll
        >      = restate what you've said with a little amplification, as = follows:
        >
        >      = "When the MG receives a non-empty Remote Descriptor = containing
        >      = multiple session descriptions, it must choose which of these
        >      = descriptions it will support and indicate its choice in its
        >      = response to the MGC.  It makes this choice according to the
        >      = following logic:
        >
        >      = (1) If the MGC did not provide a Local Descriptor in the command
        >      = and no resources were reserved for media reception by a previous
        >      = command, then the MG assumes that the stream will be send-only.
        >      It = selects the first session description in Remote that it
        >      = supports.
        >
        >      = (2) If the MGC did not provide a Local Descriptor in the = command,
        >      = but reserved resources by setting Local in a previous command,
        >      = then the MG compares the reserved resources against Remote and
        >      = chooses according to the following principles:
        >
        >      = (a) If possible, the MG establishes a symmetric media flow, with
        >      = the same encoding for both directions.
        >
        >      = (b) If multiple choices for symmetric media flows are available,
        >      it = chooses the one most preferred by the MGC as previously set in
        >      = Local.
        >
        >      = (c) If symmetric encoding is not possible, it chooses the first
        >      = session description in Remote that it supports, and returns that
        >      = along with the complete list of session descriptions in Local = for
        >      = which it has reserved resources.
        >
        >      = (3) If the MGC provided an empty Local Descriptor in the command
        >      = what happens?  According to our previous correspondence, = it's
        >      = something like this:  the MG chooses the first session
        >      = description in Remote that it supports, but returns in Local all
        >      of = the possibilities for which it was able to reserve resources,
        >      = given the selection in Remote.
        >
        >      = (4) If the MGC provided a non-empty Local Descriptor, then the = MG
        >      = applies the principles listed in (2) to make a unique choice for
        >      = both Local and Remote.
        >
        >         = ;     -----Original Message-----
        >      = From:   Michael Thomas [SMTP:mat@cisco.com]
        >      = Sent:   Tuesday, January 04, 2000 9:43 PM
        >      = To:     Taylor, Tom-PT [CAR:B904:EXCH]
        >      = Cc:     Michael Thomas; = megaco@standards.nortelnetworks.com
        >      = Subject:        RE: Proposed Text = For Media Specification
        >
        >         = ;     Tom-PT Taylor writes:
        >       > In your = second case in step (4), why doesn't the MG converge
        >      on = the single
        >       > selection = s3 for Local and Remote?  How does it know that it
        >      = should leave
        >       > Local = unresolved?
        >
        >         = ;     You're right. There are two choices:
        >
        >         = ;     1) If we want to modify my description that = the
        >         MG = should at each Local descriptor in order
        >         and = for each descriptor it can accommodate,
        >         it = should then look into the choices in the
        >         = Remote descriptor. If it finds a matching
        >         = descriptor, it should select that SDP alone
        >         for = both Remote and Local, otherwise it
        >         = keeps checking the choices within Local
        >         = against Remote until a match if found, or
        >         = Local is exhausted. If Local is exhaused,
        >     &nbs= p;   MGt should return the Local descriptors
        >         it = can accommodate, along with the most
        >         = prefereable descriptor in Remote.
        >
        >         = ;        The advantage here is that = it preserves MGC
        >         = priorities while still converging on a symmetric
        >         = codec in a 3-way handshake.
        >
        >         = ;     2) We could leave it the way I have it, = for
        >         = which it would choose s3. If so, would
        >         you = like me to contrive an example which
        >         = actually does the negotiation right?
        >
        >         = ;            = ;           = Mike
        >
        >
        >       >
        >       > > = -----Original Message-----
        >       > > = From:      Michael Thomas = [SMTP:mat@CISCO.COM]
        >       > > = Sent:      Tuesday, January 04, 2000 11:57 = AM
        >       = >      [[TomT]]  First case = snipped.
        >       >
        >       > > For = *asynchronous* negotiation we modify the flow
        >       > > = slightly:
        >       > = >
        >       > = >
        >       > > 1) = MGC->MGo: Add { Local { s1, s2, s3} Remote {}}
        >       > = >
        >       > = >    MGC sends initial add to the originator; = remote
        >       > = >    unknown. Local choice are policy
        >       > = >
        >       > > 2) = MGo->MGC: Add =3D { Local { s1, s3} Remote {}}
        >       > = >
        >       > = >    MGo chooses s1 and s3; can't do s2 because = of
        >       > > &= nbsp;  resources
        >       > = >
        >       > > 3) = MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}}
        >       > = >
        >       > = >    MGC adds MGt, sets policy in local, sends
        >       > = >    choices in remote from MGo; note MGC = sends
        >       > = >    policy of not using s1 (for whatever = reason)
        >       > = >
        >       > > 4) = MGt->MGC: Add =3D { Local { s2, s3 } Remote {s1}}
        >       > = >
        >       > = >    MGt firstly notices that Remote has choices. = It
        >       > = >    then SHOULD take the intersection of Local = and
        >       > = >    Remote's choices and return the most = preferable
        >       > = >    choice (ie, first in list). If there is not = an
        >       > = >    intersection, MG MUST choose one in Remote = and
        >       > = >    send back the choices in Local that it = can
        >       > = >    accommodate (s2, s3).
        >       > = >
        >       > > 5) = MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }}
        >       > = >
        >       > = >    MGC modifies MGo with the choices. Note = Remote
        >       > = >    is not fully qualified. The MGC MUST at = this
        >       > = >    point remember that it needs to do a 4 = way
        >       > = >    handshake since it saw choices in remote = going
        >       > = >    to MGo
        >       > = >
        >       > > 6) = MGo->MGC: Modify =3D { Local { s1 } Remote { s3}}
        >       > = >
        >       > = >    MGo acks the Modify, and chooses s3 because = it
        >       > = >    still cannot do s2 in remote
        >       > = >
        >       > > 7) = MGC->MGt: Modify { Local { s3 } Remote { s1 }}
        >       > = >
        >       > = >    MGC transmits the final  choices to = MGt
        >       > = >
        >       > > 8) = MGt->MGC: Modify =3D { Local { s3 } Remote { s1}}
        >       > = >
        >       > = >    MGt acks the modify and we're going.
        >       > = >
        >       > = >           &n= bsp; Mike
        >       > = >
        >       > > = Rosen, Brian writes:
        >       > >  = > I think buffering is going to be needed if you are
        >      = encrypting.
        >       > >  = > The real question is whether you always have to do this,
        >      or = there
        >       > >  = > is some way to know if you might be.
        >       > >  = >
        >       > >  = > The syntax problem is pretty much a "local" thing.  = On
        >      = the originating
        >       > > = end,
        >       > >  = > you want to ask for capability.  On the terminating = end,
        >      = you want to
        >       > > ask = the
        >       > >  = > MG to make a choice.  In both cases, it's local that = this
        >      = happens in.
        >       > > = The
        >       > >  = > other end gets the result (the return from the add) as
        >      = its remote.
        >       > >  = >
        >       > >  = > The following is more detail than you need, but I thought
        >      = I'd
        >       > >  = > write down how I think it works in great detail for
        >      = others
        >       > >  = > to decide if they agree, or have a different view:
        >       > >  = >
        >     &nbs= p; > >  > More specifically, the originating end gets = the
        >      = terminating
        >       > >  = > end's local as its remote, while the terminating end gets
        >      = a
        >       > >  = > negotiated version of the originating end's local as its
        >      = remote).
        >       > >  = > Working this out a little more, the originating MGC,
        >      = having no idea
        >       > > what = the
        >       > >  = > terminating side wants, has only its local policy. It
        >      = puts this in
        >       > > local = in
        >       > >  = > the first Add.  The originating MG filters this (takes
        >      = out what it
        >       > > = can't
        >       > >  = > do), reserving worst case resources, and
        >       > >  = > returns this filtered version of local in the response to
        >      = the Add.
        >       > >  = > There is no remote at all in this Add, because the
        >      = originating MGC
        >       > >  = > doesn't know any part of what goes in remote.
        >       > >  = >
        >       > >  = > The originating MGC sends this to the terminating MGC.
        >      = The terminating
        >       > > = MG
        >       > >  = > filters the received proposal with its policy,
        >       > >  = > and sends it in remote.  If it will allow asymmetric
        >      = coding (unusual)
        >       > >  = > it could just send its policy in local, but in most
        >      = cases, it will
        >       > >  = > just present the same coding options it got from the
        >      = originating
        >       > >  = > end, filtered by it's policy (which could be reordering,
        >      as = well
        >       > >  = > as removing options) in local.
        >       > >  = >
        >       > >  = > The terminating MG gets the choices and chooses one for
        >      = local and
        >       > >  = > remote (usually the same, could be different) if it can
        >      = and returns
        >       > >  = > the single chosen value in the reply to its add.  If = it
        >      = cannot,
        >       > >  = > it means none of the offered choices are acceptable.  = In
        >      = that case
        >       > >  = > it must return an error.  The response to this error
        >      = might be
        >       > >  = > to attempt the Add again with just the terminating end's
        >      = policy,
        >       > >  = > which would be returned, and then the terminating end can
        >      = propose
        >       > >  = > those choices in a full (non fast start) negotiation.
        >       > >  = > Assuming success, the terminating MGC returns the choice
        >      to = the
        >       > > = originating
        >       > >  = > MGC, which modifies the termination, both in local and
        >       > >  = > remote.
        >       > >  = >
        >       > >  = > As with the prior discussion, this means local has what
        >      = you send,
        >       > >  = > and remote has what you receive (which is what the other
        >      = end sends).
        >       > >  = >
        >       > >  = > You see the syntax issue in local?  The originating MG
        >      = sees an
        >       > >  = > Add with an overspecified local, but returns an
        >      = overspecified local.
        >       > >  = > The terminating MG sees an Add with an overspecified
        >      = local but
        >     &nbs= p; > >  > returns a fully specified local.  The = originating MG
        >      = doesn't get
        >       > >  = > a remote with the add.  The terminating MG sees an
        >      = overspecified remote
        >       > >  = > which it returns fully specified.
        >       > >  = >
        >       > >  = > Brian
        >       > >  = >
        >       > >  = > > -----Original Message-----
        >       > >  = > > From: Michael Thomas [ <mailto:mat@cisco.com>]
        >       > >  = > > Sent: Monday, January 03, 2000 6:21 PM
        >       > >  = > > To: Rosen, Brian
        >       > >  = > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
        >       > >  = > > Subject: Re: Proposed Text For Media Specification
        >       > >  = > >
        >       > >  = > >
        >       > >  = > > Rosen, Brian writes:
        >       > >  = > >  > If true, it means if you see media before = the
        >      = modify, then you
        >       > >  = > >  > start decoding, and if the modify says = something
        >      = different than
        >       > >  = > >  > you implied from the header, it's an error.  = It
        >      = isn't necessary to
        >       > >  = > >  > wait until you get the modify before you can = process
        >      = the media.
        >       > >  = > >  > I suppose that since there is the possibility = of
        >      = asymmetric
        >       > > = coding,
        >       > >  = > >  > you can't send any media until you have the = modify.
        >       > >  = > >
        >       > >  = > >    That's what I was afraid of. This implies = that
        >      = either
        >       > >  = > >    you load all of the proposed codecs (not = just
        >       > >  = > >    account for their maximum MIPS and ram as = you
        >       > >  = > >    implied), or you  better be able to = load the
        >       > >  = > >    codec PDQ once you see the first media = packet.
        >       > >  = > >
        >       > >  = > >    A worse problem is if you want to = negotiate
        >       > >  = > >    cipher suites with payload encryption. = There,
        >       > >  = > >    unless cipher suite negotiation is tied to = the
        >       > >  = > >    type field somehow (it is not in = packetcable,
        >       > >  = > >    as one data point), you have no clue how = the
        >       > >  = > >    packet is encrypted, which effectively = causes
        >       > >  = > >    front end clipping too.
        >       > >  = > >
        >       > >  = > >    Since a 4-way handshake is a pretty = heinous
        >       > >  = > >    necessity, maybe the right thing to do = would be
        >       > >  = > >    to buffer the packets in the playback = buffer
        >       > >  = > >    and not process them until the last = Modify
        >       > >  = > >    came in -- this gives the whole = playback
        >       > >  = > >    delay for the arrival of the Modify before = you
        >       > >  = > >    had to drop the packets on the head of = the
        >       > >  = > >    queue.
        >       > >  = > >
        >       > >  = > >  > HOWEVER, this means we need syntax to = differentiate
        >      = between an
        >       > >  = > >  > add with policy, respond with capability, and = add
        >      = with policy,
        >     &nbs= p; > >  > >  > choose one and respond with = your choice.
        >       > >  = > >
        >       > >  = > >    Isn't this where Local and Remote come = into
        >       > >  = > >    play? If I see several choices in Remote = (eg
        >       > >  = > >    the other side's local), isn't that the = trigger
        >       > >  = > >    for me to choose one? Or am I all screwed = up here?
        >       > >  = > >
        >       > >  = > = >            = Mike
        >       > >  = > >  >
        >       > >  = > >  > Brian
        >       > >  = > >  >
        >       > >  = > >  > > -----Original Message-----
        >       > >  = > >  > > From: Michael Thomas [ <mailto:mat@cisco.com>]
        >       > >  = > >  > > Sent: Monday, January 03, 2000 1:47 PM
        >       > >  = > >  > > To: = MEGACO@standards.nortelnetworks.com
        >       > >  = > >  > > Subject: Re: Proposed Text For Media = Specification
        >       > >  = > >  > >
        >       > >  = > >  > >
        >       > >  = > >  > > Tom-PT Taylor writes:
        >       > >  = > >  > >  > I'm willing to follow this thought = along a bit
        >      = further.  I
        >       > >  = > >  > > think the
        >       > >  = > >  > >  > concrete difference between the = viewpoint I've
        >       > >  = > > documented and the
        >       > >  = > >  > >  > "policy-capability" = viewpoint is this: if the
        >      = MGC sends
        >       > >  = > >  > > down a number of
        >       > >  = > >  > >  > alternative session descriptions, = in my case
        >      = the MG picks
        >       > >  = > >  > > one, while in
        >       > >  = > >  > >  > Brian's case the MG replies with = all the
        >      = session
        >       > >  = > >  > > descriptions it can
        >       > >  = > >  > >  > currently support.  I am = willing to accept the
        >      = latter
        >       > >  = > >  > > proposition if we can
        >       > >  = > >  > >  > all agree on it.  From there, = I will go forward
        >      = with
        >       > >  = > >  > > Chip's distinction
        >       > >  = > >  > >  > between the roles of Local and = Remote, and I
        >      = think we'll
        >       > >  = > >  > > have a good
        >       > >  = > >  > >  > sensible result.
        >       > >  = > >  > >
        >       > >  = > >  > >    Aside from the issue of not = wanting to recreate
        >       > >  = > >  > >    syntax when you could use = SDP to do the same,
        >       > >  = > >  > >    there are three constraints = which we must
        >      = adhere
        >       > >  = > >  > >    to:
        >       > >  = > >  > >
        >       > >  = > >  > >    1) Negotiation must happen = with a three way
        >      = handshake
        >       > >  = > >  > >       between = the MGC and the two MG's: eg
        >       > >  = > > Add(o)/Add(t)/Modify(o)
        >       > >  = > >  > >       I think = that Tom's original proposal does
        >      = not meet this
        >       > >  = > >  > >       = requirement, though Brian's does.
        >       > >  = > >  > >
        >       > >  = > >  > >    2) MG's which offer the set = of codec
        >      = alternatives in
        >       > >  = > >  > >       Brian's = proposal MUST NOT be expected to
        >      = have those
        >       > >  = > >  > >       coders = actually loaded and prepared to
        >      = process media
        >       > >  = > >  > >       packets. = The MG will only prepare itself for
        >      = receipt
        >       > >  = > >  > >       of = packets when it sees a single choice.
        >       > >  = > >  > >
        >       > >  = > >  > >    3) The entire process MUST = NOT lead to front
        >      = end clipping.
        >       > >  = > >  > >       I'm not = sure how you do this given the other
        >      = constraints
        >       > >  = > >  > >       other = than making it into a 4 way handshake.
        >      = Maybe
        >       > > = somebody
        >       > >  = > >  > >       more = clever than me can solve that problem.
        >       > >  = > >  > >
        >       > >  = > >  > >
        >       > >  = > >  > = >           &n= bsp;       Mike
        >       > >  = > >  > >
        >       > >  = > >  >
        >       > >  = > >  >
        >       > >  = > >
        >       > >  = >
        >       > >  = >
        >       > = <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=
        >       > = <HTML>
        >       > = <HEAD>
        >       > <META = HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html;
        >      = charset=3Dus-ascii">
        >       > <META = NAME=3D"Generator" CONTENT=3D"MS Exchange Server = version
        >      = 5.5.2448.0">
        >       > = <TITLE>RE: Proposed Text For Media = Specification</TITLE>
        >       > = </HEAD>
        >       > = <BODY>
        >       >
        >       > = <P><FONT COLOR=3D"#0000FF" SIZE=3D2 = FACE=3D"Arial">In your second
        >      = case in step (4), why doesn't the MG converge on the single
        >      = selection s3 for Local and Remote?&nbsp; How does it know that = it
        >      = should leave Local unresolved?</FONT></P>
        >
        >         = ;      > <UL>
        >       > = <P><FONT SIZE=3D1 FACE=3D"Arial">-----Original = Message-----</FONT>
        >       > = <BR><B><FONT SIZE=3D1 = FACE=3D"Arial">From:&nbsp;&nbsp;</FONT></B= >
        >      = <FONT SIZE=3D1 FACE=3D"Arial">Michael Thomas
        >      = [SMTP:mat@CISCO.COM]</FONT>
        >
        >         = ;      > <BR><B><FONT = SIZE=3D1
        >      = FACE=3D"Arial">Sent:&nbsp;&nbsp;</FONT></B= > <FONT SIZE=3D1
        >      = FACE=3D"Arial">Tuesday, January 04, 2000 11:57 = AM</FONT>
        >
        >         = ;      > = <BR><B><I><FONT COLOR=3D"#0000FF" = SIZE=3D2
        >      = FACE=3D"Arial">[[TomT]]</FONT></I></B><= ;I></I>&nbsp;<FONT
        >      = COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial"> First = case
        >      = snipped.</FONT><B></B><B></B><B><= FONT SIZE=3D1
        >      = FACE=3D"Arial"></FONT></B>
        >
        >         = ;      > </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">For = *asynchronous* negotiation we
        >      = modify the flow</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">slightly:</FONT>
        >       > = </P>
        >       > = <BR>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">1) = MGC-&gt;MGo: Add { Local { s1,
        >      = s2, s3} Remote {}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC sends = initial
        >      = add to the originator; remote</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; unknown. Local
        >      = choice are policy</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">2) = MGo-&gt;MGC: Add =3D { Local {
        >      = s1, s3} Remote {}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo chooses s1 = and
        >      = s3; can't do s2 because of</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; = resources</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">3) = MGC-&gt;MGt: Add { Local { s2,
        >      = s3} Remote { s1, s3}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC adds MGt, = sets
        >      = policy in local, sends</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; choices in = remote
        >      = from MGo; note MGC sends</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; policy of not = using
        >      s1 = (for whatever reason)</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">4) = MGt-&gt;MGC: Add =3D { Local {
        >      = s2, s3 } Remote {s1}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt firstly = notices
        >      = that Remote has choices. It</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; then SHOULD = take
        >      = the intersection of Local and</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; Remote's = choices
        >      = and return the most preferable</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; choice (ie, = first
        >      in = list). If there is not an</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; intersection, = MG
        >      = MUST choose one in Remote and</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; send back the
        >      = choices in Local that it can</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; accommodate = (s2,
        >      = s3).</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">5) = MGC-&gt;MGo: Modify { Local {
        >      s1 = } Remote { s2, s3 }}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC modifies = MGo
        >      = with the choices. Note Remote</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; is not fully
        >      = qualified. The MGC MUST at this</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; point remember = that
        >      it = needs to do a 4 way</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; handshake since = it
        >      = saw choices in remote going</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; to = MGo</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">6) = MGo-&gt;MGC: Modify =3D { Local
        >      { = s1 } Remote { s3}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGo acks the = Modify,
        >      = and chooses s3 because it</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; still cannot do = s2
        >      in = remote</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">7) = MGC-&gt;MGt: Modify { Local {
        >      s3 = } Remote { s1 }}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGC transmits = the
        >      = final&nbsp; choices to MGt</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">8) = MGt-&gt;MGC: Modify =3D { Local
        >      { = s3 } Remote { s1}}</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&nbsp; MGt acks the = modify
        >      = and we're going.</FONT>
        >     &nbs= p; > </P>
        >       >
        >       > = <P><FONT SIZE=3D2
        >      = FACE=3D"Arial">&nbsp;&nbsp;&nbsp;&nbsp;&= ;nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
        >      = Mike</FONT>
        >       > = </P>
        >       >
        >       > = <P><FONT SIZE=3D2 FACE=3D"Arial">Rosen, Brian = writes:</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; I think buffering = is
        >      = going to be needed if you are encrypting.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; The real question = is
        >      = whether you always have to do this, or there</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; is some way to = know
        >      if = you might be.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; The syntax problem = is
        >      = pretty much a &quot;local&quot; thing.&nbsp; On the = originating
        >      = end,</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; you want to
        >      = ask for capability.&nbsp; On the terminating end, you want to = ask
        >      = the</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; MG to make a
        >      = choice.&nbsp; In both cases, it's local that this happens
        >      = in.&nbsp; The</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; other end
        >      = gets the result (the return from the add) as its = remote.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
        >       > = <BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&g= t; The following is more
        >      = detail than you need, but I thought I'd</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; write down how I
        >      = think it works in great detail for others</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; to decide if they
        >      = agree, or have a different view:</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; More = specifically,
        >      = the originating end gets the terminating</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; end's local as = its
        >      = remote, while the terminating end gets a</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; negotiated version = of
        >      = the originating end's local as its remote).</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; Working this out = a
        >      = little more, the originating MGC, having no idea what = the</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; terminating
        >      = side wants, has only its local policy. It puts this in local
        >      = in</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; the first
        >      = Add.&nbsp; The originating MG filters this (takes out what = it
        >      = can't</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; do),
        >      = reserving worst case resources, and</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; returns this = filtered
        >      = version of local in the response to the Add.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; There is no remote = at
        >      = all in this Add, because the originating MGC</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; doesn't know any = part
        >      of = what goes in remote.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; The originating = MGC
        >      = sends this to the terminating MGC.&nbsp; The terminating
        >      = MG</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; filters the
        >      = received proposal with its policy,</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; and sends it in
        >      = remote.&nbsp; If it will allow asymmetric coding = (unusual)</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it could just
        >      = send its policy in local, but in most cases, it = will</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; just present the = same
        >      = coding options it got from the originating</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; end, filtered by = it's
        >      = policy (which could be reordering, as well</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; as removing = options)
        >      in = local.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt;</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; The terminating = MG
        >      = gets the choices and chooses one for local and</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; remote (usually = the
        >      = same, could be different) if it can and returns</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; the single chosen
        >      = value in the reply to its add.&nbsp; If it = cannot,</FONT>
        >     &nbs= p; > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it means none of = the
        >      = offered choices are acceptable.&nbsp; In that = case</FONT>
        >
        >         = ;      > <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; it must
        >      = return an error.&nbsp; The response to this error might = be</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; to attempt the = Add
        >      = again with just the terminating end's policy,</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; which would be
        >      = returned, and then the terminating end can propose</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; those choices in = a
        >      = full (non fast start) negotiation.</FONT>
        >       > = <BR><FONT SIZE=3D2 = FACE=3D"Arial">&nbsp;&gt; Assuming success, = the
        >      = terminating MGC returns the choice to the = originating</FONT>
        >
        >

      ------_=_NextPart_001_01BF5BD6.B8C3E2BC-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 10 21:45:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16676 for ; Mon, 10 Jan 2000 21:45:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.787AC000@standards.nortelnetworks.com>; Mon, 10 Jan 2000 21:34:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 116719 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 10 Jan 2000 21:33:18 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4F5EEA70@standards.nortelnetworks.com>; Mon, 10 Jan 2000 21:33:18 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 10 Jan 2000 20:43:50 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 10 Jan 2000 21:43:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 10 Jan 2000 21:43:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5BDD.A5B22EA2" Message-ID: Date: Mon, 10 Jan 2000 21:43:29 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: Goutam Shaw To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5BDD.A5B22EA2 Content-Type: text/plain; charset="iso-8859-1" This is a timely intervention. Before sending the requirements off to the IESG I wanted to do one last check of the archives. I found a great deal of responsiveness to Matt's concerns, but not complete capitulation. I think the proof of the wisdom of these requirements will be found in the packages which emerge to meet them. In any event we aren't going to be held up in the way Matt feared. I am therefore going to send the requirements document in to the IESG as it stands. What follows is totally optional reading, but might make sense out of past debates. Fundamentally, I think we are all agreed (including Matt) that Megaco must work within the following logical control architectures: (1) NAS connects directly to AAA > +-------+ +-------+ > Signaling | | | | > -----------+ MGC + | AAA | > | | | server| > +---+---+ +--+----+ > | Megaco / > | / > +---+---+ / > | | AAA / > | NAS +------/ > | | > +-------+ > (2) MGC proxies AAA > +-------+ +-------+ > Signaling | | AAA | | > -----------+ MGC +--------| AAA | > | | | server| > +-+-+---+ +--+----+ > Megaco| |AAA > | | > +-+-+---+ > | | > | NAS | > | | > +-------+ > The first case places the requirement on Megaco to be able to transport anything which could be received in or derived from call signalling which is needed for NAS operation, in addition to local policy. The second case is the same as the first case if the NAS initiates the AAA transaction. The second case introduces novel elements if the MGC is the one to initiate the query to the AAA server. There are two possibilities, both of which have their challenges: (1) The response leg of the AAA transaction is passed through to the NAS using an existing AAA protocol. In this case Megaco has to have the means to tell the NAS that this information is coming, and to allow the NAS to correlate it with the related Megaco transactions. The correlating information clearly depends on the particular AAA protocol being used, so we can look forward to separate packages corresponding to the respective protocols. Goutam has suggested, I believe, the alternative that correlation is achieved by proximity, by tunneling the AAA protocol within the confines of a Megaco command. (2) The response leg of the AAA transaction is translated to a Megaco equivalent. This leads to the bottomless swamp of protocol duplication Matt warns about, except that it may not be necessary to pass everything in the AAA response down to the NAS. Some information may go no further than the MGC. This approach seems to be implicit in some of the requirements Nancy has defended. > -----Original Message----- > From: Goutam Shaw [SMTP:goutam.shaw@BRIDGEWATERSYS.COM] > Sent: Monday, January 10, 2000 6:11 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > Nancy, I'm sorry for the delayed reply. I thought we had put this matter > to rest once and for all after we had the conf. call that was attended by > Nancy, Myself, Matt and I think Gunner. > According to my opinion what we have in the requirements is not AAA. These > are configuration parameters that are call specific and have to be > conveyed to the MG before the call is terminated and SHOULD NOT AND CANNOT > BE dealt by a AAA server. The parameter should help determine how the call > is supposed to be treated and has nothing to with "AAA". > I would like to keep section d (of draft-ietf-megaco-reqs-10.txt) as it > is, that relates to the ability to configure the call adaptation rate. For > example, for a given call a service provider might want to restrict the > call to 28.8 kbps based on the call specific policy information. > > As Tom has mentioned we don't need a unanimous decision all we need is a > consensus and I believe we have it (unless I hear any major objection from > the mailing list which I haven't heard in the past on this topic). > > Regards, > ..Goutam. > > Nancy-M Greene wrote: > > > > Matt, > Megaco/H.248 is a device control protocol. It is true that for NAS, > we allow the MG itself to contact the AAA server. Yet, there will be > implementations that would have the MGC contact the AAA server. The > requirements in this section allow for the development of a NAS package IN > THE FUTURE, that would allow the information returned from the AAA server > to be passed down to the MG. How this package would be written is NOT > specified in this requirements document. > > As for your comment that ALL your comments regarding the NAS section > have been ignored, this is simply not true! Your comments have been > discussed several times on the mailing list. As editor, I have tried to > come up with compromise text again and again, and every time, you come > back saying I haven't yet succeeded in satisfying your wishes. > > Perhaps it is time for the chair to step in and see if we have rough > consensus on the requirements document or not. > > Your comment on 11.2.1 D is correct. 11.2.1 D will be removed from > the requirements document. > > Also, I don't understand your comment that the requirements document > should change, based on recent discussions of the protocol. We did update > the requirements document based on discussion at the Washington meeting. > Tom is planning to put out a companion I-D that maps the Megaco/H.248 > protocol against the requirements document. > > Nancy > > -------------------------------------------------------------------------- > > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > ---------- > From: Matt Holdrege[SMTP:matt@ASCEND.COM] > Sent: Thursday, December 23, 1999 12:00 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > It's sad to see that all my comments regarding the NAS > section have been > ignored again. So let's go through them one more time and I'll try > to put > more detail into my comments. > > At a high level, NAS requirements should be set by the NAS > requirements > working group. That's where the experts are. Also, it's easy to see > that > there are NO specific NAS requirements for MEGACO. For the basic > purposes > of MEGACO, a NAS is no different than a VoIP gateway. I can see how > you may > want to do some special things with special packages, but nothing in > the > base protocol needs to be NAS specific. > > So let's go through the NAS requirements step by step... > > A. Callback. This is all that's listed. There are many > aspects to callback > which are covered by RADIUS and are a part of the new AAA > requirements. If > all you can list is callback, you should remove this requirement and > leave > it up to AAA where it belongs. > > B. Modem types. This is also handled by RADIUS and AAA. The > MG contacts the > AAA server to instruct it on which modem to use. Remember that the > MGC and > MG are not necessarily in the same management domain. But the MG > DOES trust > it's AAA server. So that is where the information must come from and > it > works best if it is transmitted directly. If you introduce a proxy, > you > introduce a lot of difficulties. The AAA WG is trying to deal with > the > difficulties of proxy and we shouldn't jump ahead of them. > > C. D. E. F. These requirements can and should be covered by > a single > sentence. The Protocol must be able to support Q.931 IE's. F already > kind > of says this. Please be succint and less tutorial. Q.931 IE's are a > basic > requirement of all MG's. Not just NAS's. > > >g. Ability for the MGC to direct the NAS to connect to a > specific tun- > > nel, for example to an LNS, or to an AAA server. > > There are a multitude of tunnel types on the Internet. L2TP, > IPsec, IPinIP, > IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all > the same. > They are handled in different IETF working groups that have defined > their > operation and their setup. The MEGACO WG should not be dictating how > > tunnels get set up. Working groups such as L2TPEXT have defined > RADIUS to > setup their tunnels. > > H. This is already covered in the VoIP section. Reproducing > requirements is > just adding confusion. > > You mention that wiretapping has been removed, yet it is > still in 11.2.1 D. > Whether the MEGACO protocol allows wiretap or not, I don't think we > want > this specific requirement in an RFC. This was discussed at the > Washington > plenary. > > Lastly, I think this document should go through a more > lengthy last call > since we are in the holiday time. We've gone into detail at the last > two > meetings on the protocol itself and this requirements document > doesn't > accurately reflect that. > > At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote: > > >I propose WG Last Call based on this document, with the > expiry two weeks > >hence (24 December). > > > >Changes from the previous version are as follows: > > > >- removed reqt 5.6 c) Support general test capabilities, for > example > >loopbacks through the MG to test DSP operation. > >It was agreed that inward loopbacks are outside the scope of the > protocol > >- they are not part of call control, so would be handled by some > other > >maintenance protocol. Thus the above requirement is deleted. > > > >- reqt 5.7 a) - changed word call to connection > > > >- table in section 11 - removed wiretap > > > >- reqt 11.1.3.1 a) rewording of 2nd bullet on addressing - didn't > mean > >wildcarding, meant instead allowing the gateway to choose (part of) > the > >identifier > > > >The references need to be completed still, and there may be an > editor's > >note or two that should still come out. > >-----Original Message----- From: Internet-Drafts@IETF.ORG > >[SMTP:Internet-Drafts@IETF.ORG] Sent: Friday, December 10, 1999 > 8:08 > >AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: > I-D > >ACTION:draft-ietf-megaco-reqs-09.txt > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. This draft is a work item of the Media Gateway > Control > >Working Group of the IETF. > > > > Title : Media Gateway control protocol > architecture > > and requirements Author(s) > : N. > > Greene, M. Ramalho, B. Rosen Filename : > > draft-ietf-megaco-reqs-09.txt Pages : > > 45 Date : 09-Dec-99 > > > >TThis document describes protocol requirements for the Media > Gateway > >control protocol between a Media Gateway Controller and a Media > Gateway. A > >URL for this Internet-Draft > >is: > >< > > > > >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > > >Internet-Drafts are also available by anonymous FTP. Login with the > > >username "anonymous" and a password of your e-mail address. After > logging > >in, type "cd internet-drafts" and then "get > >draft-ietf-megaco-reqs-09.txt". > > > >A list of Internet-Drafts directories can be found > >in < > > or > >< > > > >sites.txt > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: mailserv@ietf.org. In the body > >type: "FILE > /internet-drafts/draft-ietf-megaco-reqs-09.txt". > > > >NOTE: The mail server at ietf.org can return the document > >in MIME-encoded form by using the "mpack" utility. To use > > >this feature, insert the command "ENCODING mime" before > the > >"FILE" command. To decode the response(s), you will need > >"munpack" or a MIME-compliant mail reader. Different > >MIME-compliant mail readers exhibit different behavior, > >especially when dealing with "multipart" MIME messages > (i.e. > >documents which have been split up into multiple > messages), so > >check your local documentation on how to manipulate these > messages. > > > >Below is the data which will enable a MIME compliant mail > >reader implementation to automatically retrieve the ASCII version > of > >the Internet-Draft. << Message: >> > << File: Card for Goutam Shaw >> ------_=_NextPart_001_01BF5BDD.A5B22EA2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-reqs-09.txt

      This is a timely = intervention.  Before sending the requirements off to the IESG I = wanted to do one last check of the archives.  I found a great deal = of responsiveness to Matt's concerns, but not complete = capitulation.  I think the proof of the wisdom of these = requirements will be found in the packages which emerge to meet = them.  In any event we aren't going to be held up in the way Matt = feared.  I am therefore going to send the requirements document in = to the IESG as it stands.

      What follows is = totally optional reading, but might make sense out of past = debates.

      Fundamentally, I = think we are all agreed (including Matt) that Megaco must work within = the following logical control architectures:

      (1) NAS connects directly to = AAA

      >          &nb= sp;   +-------+        = +-------+
      >   = Signaling  |       = |        = |       |
      >   = -----------+  MGC  = +        |  AAA  |
      >          &nb= sp;   |       = |        | server|
      >          &nb= sp;   +---+---+        = +--+----+
      >          &nb= sp;       | = Megaco       /
      >          &nb= sp;       = |            = ; /
      >          &nb= sp;   +---+---+        = /
      >          &nb= sp;   |       |   AAA = /
      >          &nb= sp;   |  NAS  +------/
      >          &nb= sp;   |       = |       
      >          &nb= sp;   +-------+        =
      >

      (2) MGC proxies AAA

      >          &nb= sp;   +-------+        = +-------+
      >   = Signaling  |       |  = AAA   |       |
      >   -----------+&nb= sp; MGC  +--------|  AAA  |
      >          &nb= sp;   |       = |        | server|
      >          &nb= sp;   +-+-+---+        = +--+----+
      >          Megaco| = |AAA    
      >          &nb= sp;     | |
      >          &nb= sp;   +-+-+---+
      >          &nb= sp;   |       |
      >          &nb= sp;   |  NAS  |
      >          &nb= sp;   |       |
      >          &nb= sp;   +-------+
      >

      The first case = places the requirement on Megaco to be able to transport anything which = could be received in or derived from call signalling which is needed = for NAS operation, in addition to local policy.  The second case = is the same as the first case if the NAS initiates the AAA = transaction.

      The second case = introduces novel elements if the MGC is the one to initiate the query = to the AAA server.  There are two possibilities, both of which = have their challenges:

      (1) The response leg = of the AAA transaction is passed through to the NAS using an existing = AAA protocol.  In this case Megaco has to have the means to tell = the NAS that this information is coming, and to allow the NAS to = correlate it with the related Megaco transactions.  The = correlating information clearly depends on the particular AAA protocol = being used, so we can look forward to separate packages corresponding = to the respective protocols.  Goutam has suggested, I believe, the = alternative that correlation is achieved by proximity, by tunneling the = AAA protocol within the confines of a Megaco command.

       
      (2) The response = leg of the AAA transaction is translated to a Megaco equivalent.  = This leads to the bottomless swamp of protocol duplication Matt warns = about, except that it may not be necessary to pass everything in the = AAA response down to the NAS.  Some information may go no further = than the MGC.  This approach seems to be implicit in some of the = requirements Nancy has defended.


        -----Original Message-----
        From:   Goutam Shaw = [SMTP:goutam.shaw@BRIDGEWATERSYS.COM]
        Sent:   Monday, January 10, 2000 6:11 PM
        To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
        Subject:       = Re: I-D = ACTION:draft-ietf-megaco-reqs-09.txt

        Nancy, I'm sorry for the delayed = reply. I thought we had put this matter to rest once and for all after = we had the conf. call that was attended by Nancy, Myself, Matt and I = think Gunner.
        According to my opinion what we have in the requirements is not AAA. = These are configuration parameters that are call specific and have to = be conveyed to the MG before the call is terminated and SHOULD NOT AND = CANNOT BE dealt by a AAA server. The parameter should help determine = how the call is supposed to be treated and has nothing to with = "AAA".
        I would like to keep section d (of draft-ietf-megaco-reqs-10.txt)  = as it is, that relates to the ability to configure the call adaptation = rate. For example, for a given call a service provider might want to = restrict the call to 28.8 kbps based on the call specific policy = information.

        As Tom has mentioned we don't need a = unanimous decision all we need is a consensus and I believe we have it = (unless I hear any major objection from the mailing list which I = haven't heard in the past on this topic).

        Regards,
        ..Goutam.

        Nancy-M Greene wrote:

           

          Matt,
          Megaco/H.248 is = a device control protocol. It is true that for NAS, we allow the MG = itself to contact the AAA server. Yet, there will be implementations = that would have the MGC contact the AAA server. The requirements in = this section allow for the development of a NAS package IN THE FUTURE, = that would allow the information returned from the AAA server to be = passed down to the MG. How this package would be written is NOT = specified in this requirements document.

          As for your comment = that ALL your comments regarding the NAS section have been ignored, = this is simply not true! Your comments have been discussed several = times on the mailing list. As editor, I have tried to come up with = compromise text again and again, and every time, you come back saying I = haven't yet succeeded in satisfying your wishes.

          Perhaps it is time = for the chair to step in and see if we have rough consensus on the = requirements document or not. =

          Your comment on = 11.2.1 D is correct. 11.2.1 D will be removed from the requirements = document.

          Also, I don't = understand your comment that the requirements document should change, = based on recent discussions of the protocol. We did update the = requirements document based on discussion at the Washington meeting. = Tom is planning to put out a companion I-D that maps the Megaco/H.248 = protocol against the requirements document.

          Nancy
          -----------------------------------------------------------------= ---------
          Nancy M. = Greene
          Internet & Service = Provider Networks, Nortel Networks
          T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

                  ----------
          From:<= FONT SIZE=3D2 FACE=3D"Arial">             Matt Holdrege[SMTP:matt@ASCEND.COM]
          Sent:   Thursday, December 23, 1999 12:00 PM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:        Re: I-D = ACTION:draft-ietf-megaco-reqs-09.txt

                  It's sad to see that all my comments regarding the NAS = section have been
          ignored again. So let's go through them one more time and I'll try to = put
          more detail into my comments.

                  At a high level, NAS requirements should be set by the = NAS requirements
          working group. That's where the experts are. Also, it's easy to see = that
          there are NO specific NAS requirements for MEGACO. For the basic = purposes
          of MEGACO, a NAS is no different than a VoIP gateway. I can see how you = may
          want to do some special things with special packages, but nothing in = the
          base protocol needs to be NAS specific.

                  So let's go through the NAS requirements step by step... =

                  A. Callback. This is all that's listed. There are many = aspects to callback
          which are covered by RADIUS and are a part of the new AAA requirements. = If
          all you can list is callback, you should remove this requirement and = leave
          it up to AAA where it belongs.

                  B. Modem types. This is also handled by RADIUS and AAA. = The MG contacts the
          AAA server to instruct it on which modem to use. Remember that the MGC = and
          MG are not necessarily in the same management domain. But the MG DOES = trust
          it's AAA server. So that is where the information must come from and = it
          works best if it is transmitted directly. If you introduce a proxy, = you
          introduce a lot of difficulties. The AAA WG is trying to deal with = the
          difficulties of proxy and we shouldn't jump ahead of them.

                  C. D. E. F. These requirements can and should be covered = by a single
          sentence. The Protocol must be able to support Q.931 IE's. F already = kind
          of says this. Please be succint and less tutorial. Q.931 IE's are a = basic
          requirement of all MG's. Not just NAS's.

                   >g.   Ability for the MGC to direct the = NAS to connect to a specific tun-
           >     nel, for example to an LNS, or to an = AAA server.

                  There are a multitude of tunnel types on the Internet. = L2TP, IPsec, IPinIP,
          IPSRA, RSIP, GRE, PPTP, ATMP, etc. These tunnel types are not all the = same.
          They are handled in different IETF working groups that have defined = their
          operation and their setup. The MEGACO WG should not be dictating = how
          tunnels get set up. Working groups such as L2TPEXT have defined RADIUS = to
          setup their tunnels.

                  H. This is already covered in the VoIP section. = Reproducing requirements is
          just adding confusion.

                  You mention that wiretapping has been removed, yet it is = still in 11.2.1 D.
          Whether the MEGACO protocol allows wiretap or not, I don't think we = want
          this specific requirement in an RFC. This was discussed at the = Washington
          plenary.

                  Lastly, I think this document should go through a more = lengthy last call
          since we are in the holiday time. We've gone into detail at the last = two
          meetings on the protocol itself and this requirements document = doesn't
          accurately reflect that.

                  At 09:41 AM 12/10/99 -0500, Tom-PT Taylor wrote:

                  >I propose WG Last Call based on this document, with = the expiry two weeks
          >hence (24 December).
          >
          >Changes from the previous version are as follows:
          >
          >- removed reqt 5.6 c) Support general test capabilities, for = example
          >loopbacks through the MG to test DSP operation.
          >It was agreed that inward loopbacks are outside the scope of the = protocol
          >- they are not part of call control, so would be handled by some = other
          >maintenance protocol. Thus the above requirement is deleted.
          >
          >- reqt 5.7 a) - changed word call to connection
          >
          >- table in section 11 - removed  wiretap
          >
          >- reqt 11.1.3.1 a) rewording of 2nd bullet  on addressing - = didn't mean
          >wildcarding, meant instead allowing the gateway to choose (part of) = the
          >identifier
          >
          >The references need to be completed still, and there may be an = editor's
          >note or two that should still come out.
          >-----Original Message-----  From:   = Internet-Drafts@IETF.ORG
          >[SMTP:Internet-Drafts@IETF.ORG]  Sent:   Friday, = December 10, 1999 8:08
          >AM  To:     = MEGACO@STANDARDS.NORTELNETWORKS.COM  = Subject:        I-D
          >ACTION:draft-ietf-megaco-reqs-09.txt
          >
          >A New Internet-Draft is available from the on-line = Internet-Drafts
          >directories.  This draft is a work item of the Media Gateway = Control
          >Working Group of the IETF.
          >
          >         = Title           : = Media Gateway control protocol architecture
          > = and           &nb= sp;           &nb= sp;    = requirements          = Author(s)       : N.
          > Greene,  M. Ramalho,  B. = Rosen          = Filename        :
          > = draft-ietf-megaco-reqs-09.txt       &= nbsp;  = Pages           :
          > 45          = Date            = : 09-Dec-99
          >
          >TThis document describes protocol requirements for the Media = Gateway
          >control protocol between a Media Gateway Controller and a Media = Gateway. A
          >URL for this Internet-Draft
          >is:
          ><           <http://www.ietf.org/internet-drafts/draft-ietf-megaco-= reqs-09.txt>><= U> <http://w>
          >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt
          >
          >Internet-Drafts are also available by anonymous FTP. Login with = the
          >username  "anonymous" and a password of your e-mail = address. After logging
          >in,  type "cd internet-drafts" and = then          = "get
          >draft-ietf-megaco-reqs-09.txt".
          >
          >A list of Internet-Drafts directories can be found
          >in  <           <http://www.ietf.org/shadow.html>> <http://www.ietf.org/shadow.html>  or
          >< <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>          > <ftp://ftp.ietf.org/ietf/1shadow->
          >sites.txt
          >
          >Internet-Drafts can also be obtained by e-mail.
          >
          >Send a message = to:          = mailserv@ietf.org.  In the body
          >type:          = "FILE /internet-drafts/draft-ietf-megaco-reqs-09.txt".
          >
          >NOTE:   The mail server at ietf.org can return the = document
          >in          = MIME-encoded form by using the "mpack" utility.  To = use
          >this          feature, = insert the command "ENCODING mime" before the
          >"FILE"        &nbs= p; command.  To decode the response(s), you will need
          >"munpack" = or          a = MIME-compliant mail reader.  Different
          >MIME-compliant mail = readers          exhibit = different behavior,
          >especially when dealing = with          = "multipart" MIME messages (i.e.
          >documents which have been = split          up into = multiple messages), so
          >check your local documentation = on          how to = manipulate these messages.
          >
          >Below is the data which will enable a MIME compliant mail
          >reader  implementation to automatically retrieve the ASCII = version of
          >the  Internet-Draft. << Message:  >>

         << File: Card for Goutam = Shaw >>

      ------_=_NextPart_001_01BF5BDD.A5B22EA2-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 03:12:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02445 for ; Tue, 11 Jan 2000 03:12:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C655C70@standards.nortelnetworks.com>; Tue, 11 Jan 2000 3:01:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117133 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 03:00:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3911730@standards.nortelnetworks.com>; Tue, 11 Jan 2000 3:00:01 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 02:06:54 -0600 Received: from tlhuph12.elex.co.il (actually ertpg3e0.us.nortel.com) by zmers013; Tue, 11 Jan 2000 03:06:39 -0500 Received: from cpm.elex.co.il (cpm.elex.co.il [141.226.9.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA17630 for ; Tue, 11 Jan 2000 10:05:58 +0200 (IST) Received: from tlcpmh19.elex.co.il by cpm.elex.co.il (8.8.8+Sun/SMI-SVR4) id KAA20463; Tue, 11 Jan 2000 10:05:57 +0200 (IST) Received: (from mrk@localhost) by tlcpmh19.elex.co.il (8.8.6 (PHNE_14041)/8.7.3) id KAA09114; Tue, 11 Jan 2000 10:05:56 +0200 (IST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.32 under Emacs 19.34.1 Message-ID: <200001110805.KAA09114@tlcpmh19.elex.co.il> Date: Tue, 11 Jan 2000 10:05:56 +0200 Reply-To: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" Sender: "Media Gateway Control (megaco)" From: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Is it possible to have the following logical control architecture as well? | +-------+ +-------+ Signaling | | | | | -----------+ MGC + | AAA | | | | | server| +---+---+ +---+---+ | Megaco | | AAA | | +---+---+ | +---+---+ | | L2TP | | | NAS +--------|---------+ LNS | | (LAC) | | | +-------+ | +-------+ PSTN | ISP If yes, is it supposed to support it by the same NAS package or a separate LAC package will be required? -- ========================================================================= Mark Rasin, Senior S/W Engineer Telrad Networks, Nortel SBU e-mail: Mark.Rasin@telrad.co.il P.O.Box 50 Lod 71100, Israel Voice: +972.8.913.4084 ESN/828-4084 Fax: +972.8.913.4914 ESN/828-4914 ========================================================================= >>>>> "Tom" == Tom-PT Taylor writes: Tom> This is a timely intervention. Before sending the requirements off to the Tom> IESG I wanted to do one last check of the archives. I found a great deal of Tom> responsiveness to Matt's concerns, but not complete capitulation. I think Tom> the proof of the wisdom of these requirements will be found in the packages Tom> which emerge to meet them. In any event we aren't going to be held up in Tom> the way Matt feared. I am therefore going to send the requirements document Tom> in to the IESG as it stands. Tom> What follows is totally optional reading, but might make sense out of past Tom> debates. Tom> Fundamentally, I think we are all agreed (including Matt) that Megaco must Tom> work within the following logical control architectures: Tom> (1) NAS connects directly to AAA >> +-------+ +-------+ >> Signaling | | | | >> -----------+ MGC + | AAA | >> | | | server| >> +---+---+ +--+----+ >> | Megaco / >> | / >> +---+---+ / >> | | AAA / >> | NAS +------/ >> | | >> +-------+ >> Tom> (2) MGC proxies AAA >> +-------+ +-------+ >> Signaling | | AAA | | >> -----------+ MGC +--------| AAA | >> | | | server| >> +-+-+---+ +--+----+ >> Megaco| |AAA >> | | >> +-+-+---+ >> | | >> | NAS | >> | | >> +-------+ >> Tom> The first case places the requirement on Megaco to be able to transport Tom> anything which could be received in or derived from call signalling which is Tom> needed for NAS operation, in addition to local policy. The second case is Tom> the same as the first case if the NAS initiates the AAA transaction. Tom> The second case introduces novel elements if the MGC is the one to initiate Tom> the query to the AAA server. There are two possibilities, both of which Tom> have their challenges: Tom> (1) The response leg of the AAA transaction is passed through to the NAS Tom> using an existing AAA protocol. In this case Megaco has to have the means Tom> to tell the NAS that this information is coming, and to allow the NAS to Tom> correlate it with the related Megaco transactions. The correlating Tom> information clearly depends on the particular AAA protocol being used, so we Tom> can look forward to separate packages corresponding to the respective Tom> protocols. Goutam has suggested, I believe, the alternative that Tom> correlation is achieved by proximity, by tunneling the AAA protocol within Tom> the confines of a Megaco command. Tom> (2) The response leg of the AAA transaction is translated to a Megaco Tom> equivalent. This leads to the bottomless swamp of protocol duplication Matt Tom> warns about, except that it may not be necessary to pass everything in the Tom> AAA response down to the NAS. Some information may go no further than the Tom> MGC. This approach seems to be implicit in some of the requirements Nancy Tom> has defended. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 05:44:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03183 for ; Tue, 11 Jan 2000 05:44:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.60B3E260@standards.nortelnetworks.com>; Tue, 11 Jan 2000 5:33:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117301 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 05:32:17 -0500 Received: from smtp1.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38E85A90@standards.nortelnetworks.com>; Tue, 11 Jan 2000 5:32:16 -0500 Received: from oleane (dyn-1-1-186.Vin.dialup.oleane.fr [195.25.4.186]) by smtp1.cluster.oleane.net with SMTP id LAA18920; Tue, 11 Jan 2000 11:40:20 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0079_01BF5C28.461CC100" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <007c01bf5c1f$e584f220$0401a8c0@oleane.com> Date: Tue, 11 Jan 2000 11:37:43 +0100 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: SIP 2000 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0079_01BF5C28.461CC100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP 2000: beyond H.323?=20 Discussing and debating in Paris May 10-12. A CFP is online at: http://www.upperside.fr/basip.htm ------=_NextPart_000_0079_01BF5C28.461CC100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
      SIP 2000: beyond H.323? =
      Discussing and debating in Paris May = 10-12.
      A CFP is online at:
      http://www.upperside.fr/basip.= htm
       
      ------=_NextPart_000_0079_01BF5C28.461CC100-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 08:14:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07247 for ; Tue, 11 Jan 2000 08:14:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4470E160@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:02:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117634 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 08:01:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1EE166E0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:01:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 07:10:30 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 08:10:09 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 07:10:07 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 07:09:58 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Digit Map Symbols To: MEGACO@STANDARDS.NORTELNETWORKS.COM It has troubled me that the syntax for digit maps contains symbols which are signalling system specific (particularly the MF symbols). I propose the following alternative: 1. The digit map symbol set consists of the digits "0" through "9" and "A" through "F" (besides the extra stuff like "x", "L", and "S"). 2. A package may define a mapping between events of that package and symbols of the digit map symbol set. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 08:32:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08079 for ; Tue, 11 Jan 2000 08:32:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.82014EF0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:18:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117661 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 08:18:48 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C1028E0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:18:48 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 07:26:39 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 08:26:15 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 07:26:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C37.6D4ECA20" Message-ID: Date: Tue, 11 Jan 2000 07:25:59 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: "Rasin, Mark (M.) [SMTPPART:LOD:Telrad]" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5C37.6D4ECA20 Content-Type: text/plain; charset="iso-8859-1" Yes, you're tight, and the requirement is covered. I'll have to check what our packages people have put together, but it may be that a LAC extension to the basic NAS package would make sense. > -----Original Message----- > From: Rasin, Mark [Partner:LOD:Telrad] > Sent: Tuesday, January 11, 2000 3:06 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > Is it possible to have the following logical control architecture as > well? > > | > +-------+ +-------+ > Signaling | | | | | > -----------+ MGC + | AAA | > | | | | server| > +---+---+ +---+---+ > | Megaco | | AAA > | | > +---+---+ | +---+---+ > | | L2TP | | > | NAS +--------|---------+ LNS | > | (LAC) | | | > +-------+ | +-------+ > > PSTN | ISP > > > If yes, is it supposed to support it by the same NAS package or > a separate LAC package will be required? > > -- > ========================================================================= > Mark Rasin, Senior S/W Engineer Telrad Networks, Nortel SBU > e-mail: Mark.Rasin@telrad.co.il P.O.Box 50 Lod 71100, Israel > Voice: +972.8.913.4084 ESN/828-4084 Fax: +972.8.913.4914 ESN/828-4914 > ========================================================================= > > >>>>> "Tom" == Tom-PT Taylor writes: > > Tom> This is a timely intervention. Before sending the requirements > off to the > Tom> IESG I wanted to do one last check of the archives. I found a > great deal of > Tom> responsiveness to Matt's concerns, but not complete capitulation. > I think > Tom> the proof of the wisdom of these requirements will be found in > the packages > Tom> which emerge to meet them. In any event we aren't going to be > held up in > Tom> the way Matt feared. I am therefore going to send the > requirements document > Tom> in to the IESG as it stands. > > Tom> What follows is totally optional reading, but might make sense > out of past > Tom> debates. > > Tom> Fundamentally, I think we are all agreed (including Matt) that > Megaco must > Tom> work within the following logical control architectures: > > Tom> (1) NAS connects directly to AAA > > >> +-------+ +-------+ > >> Signaling | | | | > >> -----------+ MGC + | AAA | > >> | | | server| > >> +---+---+ +--+----+ > >> | Megaco / > >> | / > >> +---+---+ / > >> | | AAA / > >> | NAS +------/ > >> | | > >> +-------+ > >> > > Tom> (2) MGC proxies AAA > > >> +-------+ +-------+ > >> Signaling | | AAA | | > >> -----------+ MGC +--------| AAA | > >> | | | server| > >> +-+-+---+ +--+----+ > >> Megaco| |AAA > >> | | > >> +-+-+---+ > >> | | > >> | NAS | > >> | | > >> +-------+ > >> > > Tom> The first case places the requirement on Megaco to be able to > transport > Tom> anything which could be received in or derived from call > signalling which is > Tom> needed for NAS operation, in addition to local policy. The > second case is > Tom> the same as the first case if the NAS initiates the AAA > transaction. > > Tom> The second case introduces novel elements if the MGC is the one > to initiate > Tom> the query to the AAA server. There are two possibilities, both > of which > Tom> have their challenges: > > Tom> (1) The response leg of the AAA transaction is passed through to > the NAS > Tom> using an existing AAA protocol. In this case Megaco has to have > the means > Tom> to tell the NAS that this information is coming, and to allow the > NAS to > Tom> correlate it with the related Megaco transactions. The > correlating > Tom> information clearly depends on the particular AAA protocol being > used, so we > Tom> can look forward to separate packages corresponding to the > respective > Tom> protocols. Goutam has suggested, I believe, the alternative that > Tom> correlation is achieved by proximity, by tunneling the AAA > protocol within > Tom> the confines of a Megaco command. > > Tom> (2) The response leg of the AAA transaction is translated to a > Megaco > Tom> equivalent. This leads to the bottomless swamp of protocol > duplication Matt > Tom> warns about, except that it may not be necessary to pass > everything in the > Tom> AAA response down to the NAS. Some information may go no further > than the > Tom> MGC. This approach seems to be implicit in some of the > requirements Nancy > Tom> has defended. ------_=_NextPart_001_01BF5C37.6D4ECA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-reqs-09.txt

      Yes, you're tight, = and the requirement is covered.  I'll have to check what our = packages people have put together, but it may be that a LAC extension = to the basic NAS package would make sense.

        -----Original Message-----
        From:   Rasin, Mark [Partner:LOD:Telrad]
        Sent:   Tuesday, January 11, 2000 3:06 AM
        To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
        Subject:       = Re: I-D = ACTION:draft-ietf-megaco-reqs-09.txt

          Is it possible to have the = following logical control architecture as well?

                 &nb= sp;           &nb= sp;         |
                 &nb= sp;    = +-------+          &nb= sp;       +-------+
           Signaling  = |       = |        = |         = |       |
           -----------+  = MGC  = +            = ;      |  AAA  |
                 &nb= sp;    |       = |        = |         | server|
                 &nb= sp;    = +---+---+          &nb= sp;       +---+---+
                 &nb= sp;        | = Megaco     = |            = ; | AAA
                 &nb= sp;        = |            = ;            = ;  |
                 &nb= sp;    = +---+---+        = |         +---+---+
                 &nb= sp;    |       |  = L2TP            = |       |
                 &nb= sp;    |  NAS  +--------|---------+  = LNS  |
                 &nb= sp;    | (LAC) |       = ;           = |       |
                 &nb= sp;    = +-------+        = |         +-------+

                 &nb= sp;      = PSTN           = |           = ISP


           If yes, is it supposed to = support it by the same NAS package or
        a separate LAC package will be = required?

        --
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
         Mark Rasin, Senior S/W = Engineer       Telrad Networks, Nortel = SBU
         e-mail: = Mark.Rasin@telrad.co.il       P.O.Box 50 = Lod 71100, Israel
         Voice: +972.8.913.4084 = ESN/828-4084   Fax: +972.8.913.4914 ESN/828-4914
        =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

        >>>>> "Tom" = =3D=3D Tom-PT Taylor <taylor@NORTELNETWORKS.COM> writes:

            Tom> This is a = timely intervention.  Before sending the requirements off to = the
            Tom> IESG I = wanted to do one last check of the archives.  I found a great deal = of
            Tom> = responsiveness to Matt's concerns, but not complete capitulation.  = I think
            Tom> the proof = of the wisdom of these requirements will be found in the = packages
            Tom> which = emerge to meet them.  In any event we aren't going to be held up = in
            Tom> the way = Matt feared.  I am therefore going to send the requirements = document
            Tom> in to the = IESG as it stands.

            Tom> What = follows is totally optional reading, but might make sense out of = past
            Tom> = debates.

            Tom> = Fundamentally, I think we are all agreed (including Matt) that Megaco = must
            Tom> work = within the following logical control architectures:

            Tom> (1) NAS = connects directly to AAA

            = >>          &nbs= p; +-------+        +-------+
            >> = Signaling  |       = |        = |       |
            >> = -----------+  MGC  = +        |  AAA  |
            = >>          &nbs= p; |       = |        | server|
            = >>          &nbs= p; +---+---+        +--+----+
            = >>          &nbs= p;     | Megaco       = /
            = >>          &nbs= p;     = |            = ; /
            = >>          &nbs= p; +---+---+        /
            = >>          &nbs= p; |       |   AAA /
            = >>          &nbs= p; |  NAS  +------/
            = >>          &nbs= p; |       |
            = >>          &nbs= p; +-------+
            >>

            Tom> (2) MGC = proxies AAA

            = >>          &nbs= p; +-------+        +-------+
            >> = Signaling  |       |  = AAA   |       |
            >> = -----------+  MGC  +--------|  AAA  |
            = >>          &nbs= p; |       = |        | server|
            = >>          &nbs= p; +-+-+---+        +--+----+
            = >>        Megaco| |AAA
            = >>          &nbs= p;   | |
            = >>          &nbs= p; +-+-+---+
            = >>          &nbs= p; |       |
            = >>          &nbs= p; |  NAS  |
            = >>          &nbs= p; |       |
            = >>          &nbs= p; +-------+
            >>

            Tom> The first = case places the requirement on Megaco to be able to transport
            Tom> anything = which could be received in or derived from call signalling which = is
            Tom> needed for = NAS operation, in addition to local policy.  The second case = is
            Tom> the same = as the first case if the NAS initiates the AAA transaction.

            Tom> The second = case introduces novel elements if the MGC is the one to initiate
            Tom> the query = to the AAA server.  There are two possibilities, both of = which
            Tom> have their = challenges:

            Tom> (1) The = response leg of the AAA transaction is passed through to the NAS
            Tom> using an = existing AAA protocol.  In this case Megaco has to have the = means
            Tom> to tell = the NAS that this information is coming, and to allow the NAS to
            Tom> correlate = it with the related Megaco transactions.  The correlating
            Tom> = information clearly depends on the particular AAA protocol being used, = so we
            Tom> can look = forward to separate packages corresponding to the respective
            Tom> = protocols.  Goutam has suggested, I believe, the alternative = that
            Tom> = correlation is achieved by proximity, by tunneling the AAA protocol = within
            Tom> the = confines of a Megaco command.

            Tom> (2) The = response leg of the AAA transaction is translated to a Megaco
            Tom> = equivalent.  This leads to the bottomless swamp of protocol = duplication Matt
            Tom> warns = about, except that it may not be necessary to pass everything in = the
            Tom> AAA = response down to the NAS.  Some information may go no further than = the
            Tom> MGC.  = This approach seems to be implicit in some of the requirements = Nancy
            Tom> has = defended.

      ------_=_NextPart_001_01BF5C37.6D4ECA20-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 08:53:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09032 for ; Tue, 11 Jan 2000 08:53:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCF91AD0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:42:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117716 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 08:40:57 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E547E10@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:30:56 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA10521; Tue, 11 Jan 2000 08:41:28 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA24307; Tue, 11 Jan 2000 08:41:16 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 08:38:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF068629@whq-msgusr-02.fore.com> Date: Tue, 11 Jan 2000 08:41:06 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposed Text For Media Specification X-To: Christian Groves , "Tom Taylor (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Reserve All is misleading. I don't think that it means anything different from what was discussed some time ago, which is that when the MG proposes a list of potential choices, it must be prepared to accept media on any ONE of them, not ALL of them. Suppose it took 1 units of compute power to encode/decode G.711, 5 units to process G.723 and 3 to process G.729a. If the originating MG proposes G.711, G.723, G.729a, it must reserve 5 units, not 9 units! I still think we are confused about the difference between the MG responding with multiple choices, and the MG being given multiple choices. At the originating MG if you are given multiple choices, its policy from MGC to MG. You can respond with multiple choices, which is your proposal, and you must RESERVE the worst case resources. At the Terminating MG, if you are given multiple choices, you must CHOOSE, and you always commit resources for the one session description, if that was the only thing offered, or among the choices, if more than one was offered. So we need some syntax, and the distinction probably ought to be RESERVE and CHOOSE. It's annoying to have to do it in LocalControl because that is the only thing you need LocalControl for, so we have an entire descriptor with one parameter, always followed by another descriptor. It's tempting to me to get the syntax into the local/remote descriptor. Easy in binary, but some SDP in text. Maybe just another keyword. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Tuesday, January 11, 2000 4:15 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Proposed Text For Media Specification > > > G'Day Tom, > > I support the introduction of parameters for 'choose' or > 'reserveALL' to > support Fast Connect. > > Would another alternative to Local Control to be to add it to the > command syntax as 'choose' or 'reserve' would be related to commands? > ie. > ADD(Ctxt1),T1,[reserve+choose],Local[P1=v1,p2=v2],Remote[p3=v3,p4=v4] > > Cheers, Christian > > Tom-PT Taylor wrote: > > > > Unfortunately this doesn't seem to be quite the last word. From > > H.323v2 section 8.1.7 "Fast Connect Procedure", here is how fast > > connect works. > > > > > > > > "The calling endpoint initiates the Fast Connect procedure > by sending > > a SETUP message containing the > > fastStart element to the called endpoint. The fastStart element > > consists of a sequence of > > OpenLogicalChannel structures describing media channels which the > > calling endpoint proposes to send > > and receive, including all of the parameters necessary to > immediately > > open and begin transferring > > media on the channels. Details of the content and usage of the > > fastStart element are discussed below. > > ... > > "The called endpoint may begin transmitting media (according to the > > channels opened) immediately > > after sending a Q.931 message containing fastStart. The calling > > endpoint must therefore be prepared > > to receive media on any of the receive channels it proposed in the > > SETUP message, since it is possible > > for the media to be received prior to the Q.931 message indicating > > precisely which channels will be > > used. Once a Q.931 message containing fastStart is received by the > > calling endpoint, the calling > > endpoint may discontinue attempting to receive media on the channels > > for which proposals were not > > accepted by the called endpoint. Note that national requirements may > > prohibit called endpoints from > > transmitting media, or limit the nature of the content of the media > > stream, prior to transmission of a > > CONNECT message; it is the responsibility of the endpoint to comply > > with applicable requirements. If > > the calling endpoint sets the mediaWaitForConnect element to TRUE in > > the SETUP message, then the > > called endpoint shall not send any media until after the CONNECT > > message is sent." > > > > > > > > Note particularly that the originating end has to reserve resources > > for both the send and receive directions of flow. This > issue here is > > that the originating end may want to reserve alternatives, > leaving the > > far end to choose from amongst them. This implies a > non-empty Remote > > Descriptor, which according to the rules stated below would > cause the > > originating MG to select a single alternative rather than reserve > > resources for everything proposed. > > > > The answer probably lies in adding a parameter to LocalControl, with > > the two values "choose" or "reserveAll". If "choose" is > specified the > > rules below are applied. Otherwise the MG reserves resources as > > specified in Local and Remote according to the listed order of > > preference, and is prepared to receive any flow listed in Local > > immediately upon responding to the MGC. > > > > One more issue here: what to fill in for the far-end address in > > Remote, pending a response from the far end? I proposed > using dashes > > earlier, but how about following a convention used in SIP and > > supplying an address consisting of all zeroes? > > > > -----Original Message----- > > From: Taylor, Tom-PT [CAR:B904:EXCH] > > Sent: Wednesday, January 05, 2000 11:23 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Proposed Text For Media Specification > > > > I think your first alternative looks reasonable. If I > may, I'll > > restate what you've said with a little amplification, > as follows: > > > > "When the MG receives a non-empty Remote Descriptor containing > > multiple session descriptions, it must choose which of these > > descriptions it will support and indicate its choice in its > > response to the MGC. It makes this choice according to the > > following logic: > > > > (1) If the MGC did not provide a Local Descriptor in > the command > > and no resources were reserved for media reception by > a previous > > command, then the MG assumes that the stream will be send-only. > > It selects the first session description in Remote that it > > supports. > > > > (2) If the MGC did not provide a Local Descriptor in > the command, > > but reserved resources by setting Local in a previous command, > > then the MG compares the reserved resources against Remote and > > chooses according to the following principles: > > > > (a) If possible, the MG establishes a symmetric media > flow, with > > the same encoding for both directions. > > > > (b) If multiple choices for symmetric media flows are > available, > > it chooses the one most preferred by the MGC as > previously set in > > Local. > > > > (c) If symmetric encoding is not possible, it chooses the first > > session description in Remote that it supports, and > returns that > > along with the complete list of session descriptions > in Local for > > which it has reserved resources. > > > > (3) If the MGC provided an empty Local Descriptor in > the command > > what happens? According to our previous correspondence, it's > > something like this: the MG chooses the first session > > description in Remote that it supports, but returns in > Local all > > of the possibilities for which it was able to reserve > resources, > > given the selection in Remote. > > > > (4) If the MGC provided a non-empty Local Descriptor, > then the MG > > applies the principles listed in (2) to make a unique > choice for > > both Local and Remote. > > > > -----Original Message----- > > From: Michael Thomas [SMTP:mat@cisco.com] > > Sent: Tuesday, January 04, 2000 9:43 PM > > To: Taylor, Tom-PT [CAR:B904:EXCH] > > Cc: Michael Thomas; megaco@standards.nortelnetworks.com > > Subject: RE: Proposed Text For Media Specification > > > > Tom-PT Taylor writes: > > > In your second case in step (4), why doesn't the MG converge > > on the single > > > selection s3 for Local and Remote? How does it know that it > > should leave > > > Local unresolved? > > > > You're right. There are two choices: > > > > 1) If we want to modify my description that the > > MG should at each Local descriptor in order > > and for each descriptor it can accommodate, > > it should then look into the choices in the > > Remote descriptor. If it finds a matching > > descriptor, it should select that SDP alone > > for both Remote and Local, otherwise it > > keeps checking the choices within Local > > against Remote until a match if found, or > > Local is exhausted. If Local is exhaused, > > MGt should return the Local descriptors > > it can accommodate, along with the most > > prefereable descriptor in Remote. > > > > The advantage here is that it preserves MGC > > priorities while still converging on a symmetric > > codec in a 3-way handshake. > > > > 2) We could leave it the way I have it, for > > which it would choose s3. If so, would > > you like me to contrive an example which > > actually does the negotiation right? > > > > Mike > > > > > > > > > > > -----Original Message----- > > > > From: Michael Thomas [SMTP:mat@CISCO.COM] > > > > Sent: Tuesday, January 04, 2000 11:57 AM > > > [[TomT]] First case snipped. > > > > > > > For *asynchronous* negotiation we modify the flow > > > > slightly: > > > > > > > > > > > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}} > > > > > > > > MGC sends initial add to the originator; remote > > > > unknown. Local choice are policy > > > > > > > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}} > > > > > > > > MGo chooses s1 and s3; can't do s2 because of > > > > resources > > > > > > > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}} > > > > > > > > MGC adds MGt, sets policy in local, sends > > > > choices in remote from MGo; note MGC sends > > > > policy of not using s1 (for whatever reason) > > > > > > > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}} > > > > > > > > MGt firstly notices that Remote has choices. It > > > > then SHOULD take the intersection of Local and > > > > Remote's choices and return the most preferable > > > > choice (ie, first in list). If there is not an > > > > intersection, MG MUST choose one in Remote and > > > > send back the choices in Local that it can > > > > accommodate (s2, s3). > > > > > > > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }} > > > > > > > > MGC modifies MGo with the choices. Note Remote > > > > is not fully qualified. The MGC MUST at this > > > > point remember that it needs to do a 4 way > > > > handshake since it saw choices in remote going > > > > to MGo > > > > > > > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}} > > > > > > > > MGo acks the Modify, and chooses s3 because it > > > > still cannot do s2 in remote > > > > > > > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }} > > > > > > > > MGC transmits the final choices to MGt > > > > > > > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}} > > > > > > > > MGt acks the modify and we're going. > > > > > > > > Mike > > > > > > > > Rosen, Brian writes: > > > > > I think buffering is going to be needed if you are > > encrypting. > > > > > The real question is whether you always have > to do this, > > or there > > > > > is some way to know if you might be. > > > > > > > > > > The syntax problem is pretty much a "local" thing. On > > the originating > > > > end, > > > > > you want to ask for capability. On the > terminating end, > > you want to > > > > ask the > > > > > MG to make a choice. In both cases, it's > local that this > > happens in. > > > > The > > > > > other end gets the result (the return from the add) as > > its remote. > > > > > > > > > > The following is more detail than you need, > but I thought > > I'd > > > > > write down how I think it works in great detail for > > others > > > > > to decide if they agree, or have a different view: > > > > > > > > > > More specifically, the originating end gets the > > terminating > > > > > end's local as its remote, while the > terminating end gets > > a > > > > > negotiated version of the originating end's > local as its > > remote). > > > > > Working this out a little more, the originating MGC, > > having no idea > > > > what the > > > > > terminating side wants, has only its local policy. It > > puts this in > > > > local in > > > > > the first Add. The originating MG filters this (takes > > out what it > > > > can't > > > > > do), reserving worst case resources, and > > > > > returns this filtered version of local in the > response to > > the Add. > > > > > There is no remote at all in this Add, because the > > originating MGC > > > > > doesn't know any part of what goes in remote. > > > > > > > > > > The originating MGC sends this to the terminating MGC. > > The terminating > > > > MG > > > > > filters the received proposal with its policy, > > > > > and sends it in remote. If it will allow asymmetric > > coding (unusual) > > > > > it could just send its policy in local, but in most > > cases, it will > > > > > just present the same coding options it got from the > > originating > > > > > end, filtered by it's policy (which could be > reordering, > > as well > > > > > as removing options) in local. > > > > > > > > > > The terminating MG gets the choices and chooses one for > > local and > > > > > remote (usually the same, could be different) if it can > > and returns > > > > > the single chosen value in the reply to its add. If it > > cannot, > > > > > it means none of the offered choices are > acceptable. In > > that case > > > > > it must return an error. The response to this error > > might be > > > > > to attempt the Add again with just the > terminating end's > > policy, > > > > > which would be returned, and then the > terminating end can > > propose > > > > > those choices in a full (non fast start) negotiation. > > > > > Assuming success, the terminating MGC returns > the choice > > to the > > > > originating > > > > > MGC, which modifies the termination, both in local and > > > > > remote. > > > > > > > > > > As with the prior discussion, this means local has what > > you send, > > > > > and remote has what you receive (which is what > the other > > end sends). > > > > > > > > > > You see the syntax issue in local? The originating MG > > sees an > > > > > Add with an overspecified local, but returns an > > overspecified local. > > > > > The terminating MG sees an Add with an overspecified > > local but > > > > > returns a fully specified local. The originating MG > > doesn't get > > > > > a remote with the add. The terminating MG sees an > > overspecified remote > > > > > which it returns fully specified. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Michael Thomas [ ] > > > > > > Sent: Monday, January 03, 2000 6:21 PM > > > > > > To: Rosen, Brian > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: Proposed Text For Media Specification > > > > > > > > > > > > > > > > > > Rosen, Brian writes: > > > > > > > If true, it means if you see media before the > > modify, then you > > > > > > > start decoding, and if the modify says something > > different than > > > > > > > you implied from the header, it's an error. It > > isn't necessary to > > > > > > > wait until you get the modify before you > can process > > the media. > > > > > > > I suppose that since there is the possibility of > > asymmetric > > > > coding, > > > > > > > you can't send any media until you have > the modify. > > > > > > > > > > > > That's what I was afraid of. This implies that > > either > > > > > > you load all of the proposed codecs (not just > > > > > > account for their maximum MIPS and ram as you > > > > > > implied), or you better be able to load the > > > > > > codec PDQ once you see the first media packet. > > > > > > > > > > > > A worse problem is if you want to negotiate > > > > > > cipher suites with payload encryption. There, > > > > > > unless cipher suite negotiation is tied to the > > > > > > type field somehow (it is not in packetcable, > > > > > > as one data point), you have no clue how the > > > > > > packet is encrypted, which effectively causes > > > > > > front end clipping too. > > > > > > > > > > > > Since a 4-way handshake is a pretty heinous > > > > > > necessity, maybe the right thing to do would be > > > > > > to buffer the packets in the playback buffer > > > > > > and not process them until the last Modify > > > > > > came in -- this gives the whole playback > > > > > > delay for the arrival of the Modify before you > > > > > > had to drop the packets on the head of the > > > > > > queue. > > > > > > > > > > > > > HOWEVER, this means we need syntax to > differentiate > > between an > > > > > > > add with policy, respond with capability, and add > > with policy, > > > > > > > choose one and respond with your choice. > > > > > > > > > > > > Isn't this where Local and Remote come into > > > > > > play? If I see several choices in Remote (eg > > > > > > the other side's local), isn't that the trigger > > > > > > for me to choose one? Or am I all screwed up here? > > > > > > > > > > > > Mike > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Michael Thomas [ ] > > > > > > > > Sent: Monday, January 03, 2000 1:47 PM > > > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > > > Subject: Re: Proposed Text For Media > Specification > > > > > > > > > > > > > > > > > > > > > > > > Tom-PT Taylor writes: > > > > > > > > > I'm willing to follow this thought > along a bit > > further. I > > > > > > > > think the > > > > > > > > > concrete difference between the > viewpoint I've > > > > > > documented and the > > > > > > > > > "policy-capability" viewpoint is this: if the > > MGC sends > > > > > > > > down a number of > > > > > > > > > alternative session descriptions, in my case > > the MG picks > > > > > > > > one, while in > > > > > > > > > Brian's case the MG replies with all the > > session > > > > > > > > descriptions it can > > > > > > > > > currently support. I am willing to > accept the > > latter > > > > > > > > proposition if we can > > > > > > > > > all agree on it. From there, I will > go forward > > with > > > > > > > > Chip's distinction > > > > > > > > > between the roles of Local and Remote, and I > > think we'll > > > > > > > > have a good > > > > > > > > > sensible result. > > > > > > > > > > > > > > > > Aside from the issue of not wanting > to recreate > > > > > > > > syntax when you could use SDP to do the same, > > > > > > > > there are three constraints which we must > > adhere > > > > > > > > to: > > > > > > > > > > > > > > > > 1) Negotiation must happen with a three way > > handshake > > > > > > > > between the MGC and the two MG's: eg > > > > > > Add(o)/Add(t)/Modify(o) > > > > > > > > I think that Tom's original proposal does > > not meet this > > > > > > > > requirement, though Brian's does. > > > > > > > > > > > > > > > > 2) MG's which offer the set of codec > > alternatives in > > > > > > > > Brian's proposal MUST NOT be expected to > > have those > > > > > > > > coders actually loaded and prepared to > > process media > > > > > > > > packets. The MG will only prepare > itself for > > receipt > > > > > > > > of packets when it sees a single choice. > > > > > > > > > > > > > > > > 3) The entire process MUST NOT lead to front > > end clipping. > > > > > > > > I'm not sure how you do this > given the other > > constraints > > > > > > > > other than making it into a 4 way > handshake. > > Maybe > > > > somebody > > > > > > > > more clever than me can solve > that problem. > > > > > > > > > > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > RE: Proposed Text For Media Specification > > > > > > > > > > > >

      In your second > > case in step (4), why doesn't the MG converge on the single > > selection s3 for Local and Remote?  How does it > know that it > > should leave Local unresolved?

      > > > > >
        > > >

        -----Original > Message----- > > >
        FACE="Arial">From:   > > Michael Thomas > > [SMTP:mat@CISCO.COM] > > > > >
        > FACE="Arial">Sent:   > FACE="Arial">Tuesday, January 04, 2000 11:57 AM > > > > >
        > FACE="Arial">[[TomT]]  > COLOR="#0000FF" SIZE=2 FACE="Arial"> First case > > snipped. > FACE="Arial"> > > > > >

        > > > > > >

        For *asynchronous* > negotiation we > > modify the flow > > >
        slightly: > > >

        > > >
        > > > > > >

        1) MGC->MGo: Add { > Local { s1, > > s2, s3} Remote {}} > > >

        > > > > > >

           MGC sends initial > > add to the originator; remote > > >
           unknown. Local > > choice are policy > > >

        > > > > > >

        2) MGo->MGC: Add = { Local { > > s1, s3} Remote {}} > > >

        > > > > > >

           MGo chooses s1 and > > s3; can't do s2 because of > > >
           resources > > >

        > > > > > >

        3) MGC->MGt: Add { > Local { s2, > > s3} Remote { s1, s3}} > > >

        > > > > > >

           MGC adds MGt, sets > > policy in local, sends > > >
           choices in remote > > from MGo; note MGC sends > > >
           policy > of not using > > s1 (for whatever reason) > > >

        > > > > > >

        4) MGt->MGC: Add = { Local { > > s2, s3 } Remote {s1}} > > >

        > > > > > >

           MGt > firstly notices > > that Remote has choices. It > > >
           then SHOULD take > > the intersection of Local and > > >
           Remote's choices > > and return the most preferable > > >
           choice (ie, first > > in list). If there is not an > > >
           intersection, MG > > MUST choose one in Remote and > > >
           send back the > > choices in Local that it can > > >
           accommodate (s2, > > s3). > > >

        > > > > > >

        5) MGC->MGo: Modify > { Local { > > s1 } Remote { s2, s3 }} > > >

        > > > > > >

           MGC modifies MGo > > with the choices. Note Remote > > >
           is not fully > > qualified. The MGC MUST at this > > >
           point > remember that > > it needs to do a 4 way > > >
           > handshake since it > > saw choices in remote going > > >
           to MGo > > >

        > > > > > >

        6) MGo->MGC: Modify > = { Local > > { s1 } Remote { s3}} > > >

        > > > > > >

           MGo acks > the Modify, > > and chooses s3 because it > > >
           still > cannot do s2 > > in remote > > >

        > > > > > >

        7) MGC->MGt: Modify > { Local { > > s3 } Remote { s1 }} > > >

        > > > > > >

           MGC transmits the > > final  choices to MGt > > >

        > > > > > >

        8) MGt->MGC: Modify > = { Local > > { s3 } Remote { s1}} > > >

        > > > > > >

           MGt acks > the modify > > and we're going. > > >

        > > > > > >

        > > FACE="Arial">        & > nbsp;   > > Mike > > >

        > > > > > >

        Rosen, Brian writes: > > >
         > I think > buffering is > > going to be needed if you are encrypting. > > >
         > The real > question is > > whether you always have to do this, or there > > >
         > is some way to know > > if you might be. > > >
         > > > >
         > The syntax > problem is > > pretty much a "local" thing.  On the originating > > end, > > > > >
         > you want to > > ask for capability.  On the terminating end, you > want to ask > > the > > > > >
         > MG > to make a > > choice.  In both cases, it's local that this happens > > in.  The > > > > >
         > other end > > gets the result (the return from the add) as its remote. > > >
         > > > >
         > The > following is more > > detail than you need, but I thought I'd > > >
         > write down how I > > think it works in great detail for others > > >
         > to decide if they > > agree, or have a different view: > > >
         > > > >
         > More specifically, > > the originating end gets the terminating > > >
         > end's local as its > > remote, while the terminating end gets a > > >
         > negotiated > version of > > the originating end's local as its remote). > > >
         > Working this out a > > little more, the originating MGC, having no idea what > the > > > > >
         > terminating > > side wants, has only its local policy. It puts this in local > > in > > > > >
         > the first > > Add.  The originating MG filters this (takes out what it > > can't > > > > >
         > do), > > reserving worst case resources, and > > >
         > returns > this filtered > > version of local in the response to the Add. > > >
         > There is > no remote at > > all in this Add, because the originating MGC > > >
         > doesn't > know any part > > of what goes in remote. > > >
         > > > >
         > The originating MGC > > sends this to the terminating MGC.  The terminating > > MG > > > > >
         > filters the > > received proposal with its policy, > > >
         > and sends it in > > remote.  If it will allow asymmetric coding > (unusual) > > > > >
         > it > could just > > send its policy in local, but in most cases, it will > > >
         > just > present the same > > coding options it got from the originating > > >
         > end, > filtered by it's > > policy (which could be reordering, as well > > >
         > as > removing options) > > in local. > > >
         > > > >
         > The terminating MG > > gets the choices and chooses one for local and > > >
         > remote (usually the > > same, could be different) if it can and returns > > >
         > the single chosen > > value in the reply to its add.  If it cannot, > > >
         > it means > none of the > > offered choices are acceptable.  In that case > > > > >
         > it must > > return an error.  The response to this error > might be > > >
         > to attempt the Add > > again with just the terminating end's policy, > > >
         > which would be > > returned, and then the terminating end can propose > > >
         > those choices in a > > full (non fast start) negotiation. > > >
         > Assuming > success, the > > terminating MGC returns the choice to the originating > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 09:06:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09664 for ; Tue, 11 Jan 2000 09:06:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F1746D0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:55:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117761 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 08:53:42 -0500 Received: from mel.alcatel.fr (212.208.74.132) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F69F40C0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 8:43:42 -0500 Received: from aifhs10.alcatel.fr (mailhub2.alcatel.fr [155.132.188.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA28750 for ; Tue, 11 Jan 2000 14:47:31 +0100 Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with SMTP id OAA05577 for ; Tue, 11 Jan 2000 14:50:01 +0100 (MET) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C1256863.004C5F85 ; Tue, 11 Jan 2000 14:54:11 +0100 X-Lotus-FromDomain: ALCATEL Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: Date: Tue, 11 Jan 2000 14:54:06 +0100 Reply-To: Francois-Xavier.Derome@ALCATEL.FR Sender: "Media Gateway Control (megaco)" From: Francois-Xavier Derome Subject: basic package To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi everybody, Can somebody clarify the status of the ietf generic packages vs the basic packages of the itu ? thanks, mailto:francois-xavier.derome@alcatel.fr From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 09:17:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10097 for ; Tue, 11 Jan 2000 09:17:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19A2D8E0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:06:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117790 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 09:04:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB976EC0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:04:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 08:15:24 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 09:15:03 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 08:15:01 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 08:14:57 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposed Text For Media Specification X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't care what you call it -- the intent is "reserve for all", whatever that means for the given MG implementation. Your example might be too simple -- remember the point that code for each codec may have to be loaded, so there could be an additive memory constraint. You need LocalControl for Mode for sure, so you can't just eliminate it. I expect we will find other uses for it too. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 11, 2000 8:41 AM > To: 'Christian Groves'; Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > Subject: RE: Proposed Text For Media Specification > > Reserve All is misleading. I don't think that it means anything > different from what was discussed some time ago, which is > that when the MG proposes a list of potential choices, it must > be prepared to accept media on any ONE of them, not ALL of them. > > Suppose it took 1 units of compute power to encode/decode G.711, > 5 units to process G.723 and 3 to process G.729a. If the > originating MG proposes G.711, G.723, G.729a, it must reserve > 5 units, not 9 units! > > I still think we are confused about the difference between > the MG responding with multiple choices, and the MG being given > multiple choices. > > At the originating MG if you are given multiple choices, > its policy from MGC to MG. You can respond with multiple choices, which > is > your proposal, and you must RESERVE the worst > case resources. At the Terminating MG, if you are given > multiple choices, you must CHOOSE, and you always commit resources for the > one session description, if that was the > only thing offered, or among the choices, if more than one > was offered. > > So we need some syntax, and the distinction probably ought to be > RESERVE and CHOOSE. It's annoying to have to do it in LocalControl > because > that is the only thing you need LocalControl for, so we have an entire > descriptor with one parameter, always followed by another descriptor. > It's > tempting to me to get the > syntax into the local/remote descriptor. Easy in binary, > but some SDP in text. Maybe just another keyword. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 09:20:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10209 for ; Tue, 11 Jan 2000 09:20:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61F1BDF0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:08:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117802 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 09:07:44 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.527BEAD0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:07:44 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 08:17:39 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 09:17:25 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 08:17:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C3E.931D4F04" Message-ID: Date: Tue, 11 Jan 2000 08:17:14 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: basic package X-To: Francois-Xavier.Derome@ALCATEL.FR To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5C3E.931D4F04 Content-Type: text/plain The basic packages of the ITU are what they had time to assimilate in Red Bank. They will probably pick up the generic packages as another Annex, to be determined at next month's meeting. If they don't, it doesn't particularly matter: our package registration rules give equal weight to packages regardless of origin. > -----Original Message----- > From: Francois-Xavier Derome [SMTP:Francois-Xavier.Derome@ALCATEL.FR] > Sent: Tuesday, January 11, 2000 8:54 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: basic package > > Hi everybody, > Can somebody clarify the status of the ietf generic packages vs the basic > packages of the itu ? > > thanks, > > mailto:francois-xavier.derome@alcatel.fr ------_=_NextPart_001_01BF5C3E.931D4F04 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: basic package

        The basic packages = of the ITU are what they had time to assimilate in Red Bank.  They = will probably pick up the generic packages as another Annex, to be = determined at next month's meeting.  If they don't, it doesn't = particularly matter: our package registration rules give equal weight = to packages regardless of origin.

          -----Original Message-----
          From:   Francois-Xavier Derome = [SMTP:Francois-Xavier.Derome@ALCATEL.FR]
          Sent:   Tuesday, January 11, 2000 8:54 AM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = basic package

          Hi everybody,
          Can somebody clarify the status of = the ietf generic packages vs the basic packages of the itu ?

          thanks,

          mailto:francois-xavier= .derome@alcatel.fr

        ------_=_NextPart_001_01BF5C3E.931D4F04-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 09:27:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10577 for ; Tue, 11 Jan 2000 09:27:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.814B4BC0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:16:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117795 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 09:14:56 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE05AFA0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 9:04:56 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA13432; Tue, 11 Jan 2000 09:15:31 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA01549; Tue, 11 Jan 2000 09:15:32 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 09:12:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF06862F@whq-msgusr-02.fore.com> Date: Tue, 11 Jan 2000 09:15:24 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: basic package X-To: "Francois-Xavier.Derome@alcatel.fr" To: MEGACO@STANDARDS.NORTELNETWORKS.COM The intention is that the ITU document and the IETF document, when first issued, will have the same text, which includes base packages. In the ITU, adding Annexes to a document is not a reissue of the document, whereas in IETF it would be. There are some additional packages that have been determined in ITU that will become annexes of H.248. It is not yet decided what IETF will do with these. They can be issued as separate RFCs, or the main RFC can be reissued. Brian > -----Original Message----- > From: Francois-Xavier Derome > [mailto:Francois-Xavier.Derome@alcatel.fr] > Sent: Tuesday, January 11, 2000 8:54 AM > To: MEGACO@standards.nortelnetworks.com > Subject: basic package > > > Hi everybody, > Can somebody clarify the status of the ietf generic packages > vs the basic packages of the itu ? > > thanks, > > mailto:francois-xavier.derome@alcatel.fr > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:02:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13778 for ; Tue, 11 Jan 2000 11:02:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE524EC0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 10:51:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 117988 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 10:51:13 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C7110200@standards.nortelnetworks.com>; Tue, 11 Jan 2000 10:51:13 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 10:01:41 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 11:01:12 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 10:01:10 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 10:01:08 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Packages Supported By A Termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM It has occurred to me that the means by which a termination becomes associated with a set of packages is quite obscure and generally indirect. For instance, support of specific bearer-type-related packages will be inferred from the nettype and addrtype used in session descriptions within the Local and Remote descriptors. Support of a DTMF package will be inferred from the use of DTMF events or signals in the respective descriptors. Is this how people see the relationship between packages and terminations in general, or do we need a more specific method of specifying support, such as a package list in TerminationState? (Note that Package Descriptor is returned from audits, but cannot be set.) Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:25:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14287 for ; Tue, 11 Jan 2000 11:25:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31A1D250@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:08:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118028 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 11:07:36 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AB90F2F0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 10:57:36 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA25090; Tue, 11 Jan 2000 11:08:12 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA02478; Tue, 11 Jan 2000 11:08:13 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 11:05:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF068631@whq-msgusr-02.fore.com> Date: Tue, 11 Jan 2000 11:08:07 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Packages Supported By A Termination X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't understand this. The packages realized by a termination is fixed, mostly at design time, possibly altered by provisioning. There isn't anything you can "set". Auditing to find out what packages are implemented is there. It's the "package list" you asked for. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, January 11, 2000 11:01 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Packages Supported By A Termination > > > It has occurred to me that the means by which a termination becomes > associated with a set of packages is quite obscure and > generally indirect. > For instance, support of specific bearer-type-related packages will be > inferred from the nettype and addrtype used in session > descriptions within > the Local and Remote descriptors. Support of a DTMF package will be > inferred from the use of DTMF events or signals in the respective > descriptors. > > Is this how people see the relationship between packages and > terminations in > general, or do we need a more specific method of specifying > support, such as > a package list in TerminationState? (Note that Package Descriptor is > returned from audits, but cannot be set.) > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 11:25:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14298 for ; Tue, 11 Jan 2000 11:25:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A0FB110@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:10:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118073 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 11:09:03 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44F2BCC0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 11:09:03 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 10:18:47 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 11 Jan 2000 11:18:28 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 11:18:27 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 11:18:16 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Packages Supported By A Termination X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM If the MGC orders up an ephemeral termination, the stack (whether ATM or IP based) supported by that termination is determined by the session descriptions in Local and Remote -- it's not pre-provisioned. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 11, 2000 11:08 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com > Subject: RE: Packages Supported By A Termination > > I don't understand this. > > The packages realized by a termination is fixed, mostly at > design time, possibly altered by provisioning. There isn't > anything you can "set". Auditing to find out what packages > are implemented is there. It's the "package list" you > asked for. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Tuesday, January 11, 2000 11:01 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Packages Supported By A Termination > > > > > > It has occurred to me that the means by which a termination becomes > > associated with a set of packages is quite obscure and > > generally indirect. > > For instance, support of specific bearer-type-related packages will be > > inferred from the nettype and addrtype used in session > > descriptions within > > the Local and Remote descriptors. Support of a DTMF package will be > > inferred from the use of DTMF events or signals in the respective > > descriptors. > > > > Is this how people see the relationship between packages and > > terminations in > > general, or do we need a more specific method of specifying > > support, such as > > a package list in TerminationState? (Note that Package Descriptor is > > returned from audits, but cannot be set.) > > > > Tom Taylor > > Advisor -- IPConnect Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 13:50:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18461 for ; Tue, 11 Jan 2000 13:50:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3DEDF740@standards.nortelnetworks.com>; Tue, 11 Jan 2000 13:39:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118476 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 13:37:21 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.96704500@standards.nortelnetworks.com>; Tue, 11 Jan 2000 13:27:20 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA09916; Tue, 11 Jan 2000 13:37:55 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA13416; Tue, 11 Jan 2000 13:37:56 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Jan 2000 13:35:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF068633@whq-msgusr-02.fore.com> Date: Tue, 11 Jan 2000 13:37:48 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Packages Supported By A Termination X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM We have not determined if there is a package associated with ATM (or IP), and what it needs to have in it. Right at the moment, unless the package defines extensions to Annex C and SDP, I don't think it has any purpose. If there are such packages, then the audit of packages tells you that you can order up a bearer of that type. We have not discussed what audit of local does, but presumably it gives you what the MG could accept as SDP/Annex C. In that case such an audit would tell you what types of ephemerals you can ask for. We certainly don't need anything else. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, January 11, 2000 11:18 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Packages Supported By A Termination > > > If the MGC orders up an ephemeral termination, the stack > (whether ATM or IP > based) supported by that termination is determined by the session > descriptions in Local and Remote -- it's not pre-provisioned. > > > -----Original Message----- > > From: Rosen, Brian [SMTP:brosen@fore.com] > > Sent: Tuesday, January 11, 2000 11:08 AM > > To: Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > > Subject: RE: Packages Supported By A Termination > > > > I don't understand this. > > > > The packages realized by a termination is fixed, mostly at > > design time, possibly altered by provisioning. There isn't > > anything you can "set". Auditing to find out what packages > > are implemented is there. It's the "package list" you > > asked for. > > > > Brian > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > Sent: Tuesday, January 11, 2000 11:01 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Packages Supported By A Termination > > > > > > > > > It has occurred to me that the means by which a > termination becomes > > > associated with a set of packages is quite obscure and > > > generally indirect. > > > For instance, support of specific bearer-type-related > packages will be > > > inferred from the nettype and addrtype used in session > > > descriptions within > > > the Local and Remote descriptors. Support of a DTMF > package will be > > > inferred from the use of DTMF events or signals in the respective > > > descriptors. > > > > > > Is this how people see the relationship between packages and > > > terminations in > > > general, or do we need a more specific method of specifying > > > support, such as > > > a package list in TerminationState? (Note that Package > Descriptor is > > > returned from audits, but cannot be set.) > > > > > > Tom Taylor > > > Advisor -- IPConnect Standards > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > > Phone and FAX: +1 613 736 0961 > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 14:01:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18712 for ; Tue, 11 Jan 2000 14:01:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9311980@standards.nortelnetworks.com>; Tue, 11 Jan 2000 13:50:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118513 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 13:48:32 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C844340@standards.nortelnetworks.com>; Tue, 11 Jan 2000 13:48:32 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 12:58:34 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 13:58:15 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 12:58:13 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Tue, 11 Jan 2000 12:58:02 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Packages Supported By A Termination X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Basically you need at least three items in an ATM package that I can think of off the top of my head: the nettype and addrtype extensions to SDP, means to specify all the ATM-related parameters (darned if I know how -- SDP attributes generally seem to be associated with codecs, not bearers), and ATM-specific statistics. I can't think of any need for an IP package at this point -- we would collect statistics at a higher level (RTP, whatever is inherent in an alternative encapsulation), and SDP doesn't need extending to handle it. We do need to extend SDP to handle TCP transport. It's all very well to say that the MG will support ephemeral terminations with this package or that package, but once an ephemeral has been instantiated, how will an audit determine the contents of the package list for that specific termination? I believe it will do it as I say, by inferring it from the termination's current properties. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 11, 2000 1:38 PM > To: Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com > Subject: RE: Packages Supported By A Termination > > We have not determined if there is a package associated with > ATM (or IP), and what it needs to have in it. Right at the > moment, unless the package defines extensions to Annex C and > SDP, I don't think it has any purpose. > > If there are such packages, then the audit of packages tells > you that you can order up a bearer of that type. > > We have not discussed what audit of local does, but presumably it > gives you what the MG could accept as SDP/Annex C. In that case > such an audit would tell you what types of ephemerals you > can ask for. > > We certainly don't need anything else. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > Sent: Tuesday, January 11, 2000 11:18 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Packages Supported By A Termination > > > > > > If the MGC orders up an ephemeral termination, the stack > > (whether ATM or IP > > based) supported by that termination is determined by the session > > descriptions in Local and Remote -- it's not pre-provisioned. > > > > > -----Original Message----- > > > From: Rosen, Brian [SMTP:brosen@fore.com] > > > Sent: Tuesday, January 11, 2000 11:08 AM > > > To: Taylor, Tom-PT [CAR:B904:EXCH]; > > MEGACO@standards.nortelnetworks.com > > > Subject: RE: Packages Supported By A Termination > > > > > > I don't understand this. > > > > > > The packages realized by a termination is fixed, mostly at > > > design time, possibly altered by provisioning. There isn't > > > anything you can "set". Auditing to find out what packages > > > are implemented is there. It's the "package list" you > > > asked for. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > > > > Sent: Tuesday, January 11, 2000 11:01 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Packages Supported By A Termination > > > > > > > > > > > > It has occurred to me that the means by which a > > termination becomes > > > > associated with a set of packages is quite obscure and > > > > generally indirect. > > > > For instance, support of specific bearer-type-related > > packages will be > > > > inferred from the nettype and addrtype used in session > > > > descriptions within > > > > the Local and Remote descriptors. Support of a DTMF > > package will be > > > > inferred from the use of DTMF events or signals in the respective > > > > descriptors. > > > > > > > > Is this how people see the relationship between packages and > > > > terminations in > > > > general, or do we need a more specific method of specifying > > > > support, such as > > > > a package list in TerminationState? (Note that Package > > Descriptor is > > > > returned from audits, but cannot be set.) > > > > > > > > Tom Taylor > > > > Advisor -- IPConnect Standards > > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > > > Phone and FAX: +1 613 736 0961 > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 14:42:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19473 for ; Tue, 11 Jan 2000 14:42:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87BDABC0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 14:31:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118592 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 14:30:05 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.59C09980@standards.nortelnetworks.com>; Tue, 11 Jan 2000 14:30:04 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 13:40:14 -0600 Received: from zrchb213.us.nortel.com by zmers013; Tue, 11 Jan 2000 14:39:49 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 13:39:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C6B.9D8EFAB4" Message-ID: Date: Tue, 11 Jan 2000 13:39:45 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Packages Supported By A Termination X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5C6B.9D8EFAB4 Content-Type: text/plain; charset="iso-8859-1" The original Annex C most assuredly has RTP and ATM things in it. Yes, it's the SDP that gets extended when we're talking text encoding. We're really in a black hole if we can't extend SDP through our documentation -- we have to have documentary support to register the stuff with IANA per the SDP RFC. I haven't managed to get together with Joerg Ott to figure out how or whether MMUSIC could do it for us instead. My musings about packages have to do with implementation rather than the protocol itself. The protocol provides the means to express the fact that a certain termination supports certain packages, but the question was how an MG implementor figured out what to put in that list. > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 11, 2000 2:09 PM > To: Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com > Subject: RE: Packages Supported By A Termination > > Statistics, that's a good reason. Let's decide - we will have RTP and ATM > packages > they will have at least statistics in them. An audit would tell you that > you can create > the appropriate ephemeral. > > The question remains, does a package get to define extensions to SDP and > Annex C? > Does the original Annex C have ATM and RTP things in it? Does the > original > document have any SDP extensions for ATM? NetType is found in both Annex > C > and SDP. In SDP we need to have the specifics, but the place to put it is > in the SDP, > and not in LocalControl, right? Same with addrtype. So if a package > could define > extensions to Annex C and SDP, then you could define the ATM extensions to > SDP in the ATM package. I'm not sure we want to allow such a thing. > > I'm still mystified what problem you see auditing. If you have an > ephemeral, > an audit will tell you what packages it implements. > AuditValue=RTPxxxxx{Audit{Packages}} > returns the list of packages implemented on the ephemeral RTPxxxxx > > Brian. > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, January 11, 2000 1:58 PM > To: Rosen, Brian; megaco@standards.nortelnetworks.com > Subject: RE: Packages Supported By A Termination > > > > Basically you need at least three items in an ATM package that I can > think of off the top of my head: the nettype and addrtype extensions to > SDP, means to specify all the ATM-related parameters (darned if I know how > -- SDP attributes generally seem to be associated with codecs, not > bearers), and ATM-specific statistics. I can't think of any need for an > IP package at this point -- we would collect statistics at a higher level > (RTP, whatever is inherent in an alternative encapsulation), and SDP > doesn't need extending to handle it. We do need to extend SDP to handle > TCP transport. > > It's all very well to say that the MG will support ephemeral > terminations with this package or that package, but once an ephemeral has > been instantiated, how will an audit determine the contents of the package > list for that specific termination? I believe it will do it as I say, by > inferring it from the termination's current properties. > > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Tuesday, January 11, 2000 1:38 PM > To: Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > Subject: RE: Packages Supported By A Termination > > We have not determined if there is a package associated with > > ATM (or IP), and what it needs to have in it. Right at the > moment, unless the package defines extensions to Annex C and > SDP, I don't think it has any purpose. > > If there are such packages, then the audit of packages tells > > you that you can order up a bearer of that type. > > We have not discussed what audit of local does, but > presumably it > gives you what the MG could accept as SDP/Annex C. In that case > such an audit would tell you what types of ephemerals you > can ask for. > > We certainly don't need anything else. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [ ] > > Sent: Tuesday, January 11, 2000 11:18 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Packages Supported By A Termination > > > > > > If the MGC orders up an ephemeral termination, the stack > > (whether ATM or IP > > based) supported by that termination is determined by the session > > descriptions in Local and Remote -- it's not pre-provisioned. > > > > > -----Original Message----- > > > From: Rosen, Brian [SMTP:brosen@fore.com] > > > Sent: Tuesday, January 11, 2000 11:08 AM > > > To: Taylor, Tom-PT [CAR:B904:EXCH]; > > MEGACO@standards.nortelnetworks.com > > > Subject: RE: Packages Supported By A Termination > > > > > > I don't understand this. > > > > > > The packages realized by a termination is fixed, mostly at > > > design time, possibly altered by provisioning. There isn't > > > anything you can "set". Auditing to find out what packages > > > are implemented is there. It's the "package list" you > > > asked for. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Tom-PT Taylor [ ] > > > > Sent: Tuesday, January 11, 2000 11:01 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Packages Supported By A Termination > > > > > > > > > > > > It has occurred to me that the means by which a > > termination becomes > > > > associated with a set of packages is quite obscure and > > > > generally indirect. > > > > For instance, support of specific bearer-type-related > > packages will be > > > > inferred from the nettype and addrtype used in session > > > > descriptions within > > > > the Local and Remote descriptors. Support of a DTMF > > package will be > > > > inferred from the use of DTMF events or signals in the > respective > > > > descriptors. > > > > > > > > Is this how people see the relationship between packages and > > > > terminations in > > > > general, or do we need a more specific method of specifying > > > > support, such as > > > > a package list in TerminationState? (Note that Package > > Descriptor is > > > > returned from audits, but cannot be set.) > > > > > > > > Tom Taylor > > > > Advisor -- IPConnect Standards > > > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > > > Phone and FAX: +1 613 736 0961 > > > > > > > ------_=_NextPart_001_01BF5C6B.9D8EFAB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Packages Supported By A Termination

        The original Annex C = most assuredly has RTP and ATM things in it.  Yes, it's the SDP = that gets extended when we're talking text encoding.

        We're really in a = black hole if we can't extend SDP through our documentation -- we have = to have documentary support to register the stuff with IANA per the SDP = RFC.  I haven't managed to get together with Joerg Ott to figure = out how or whether MMUSIC could do it for us instead.

        My musings about = packages have to do with implementation rather than the protocol = itself.  The protocol provides the means to express the fact that = a certain termination supports certain packages, but the question was = how an MG implementor figured out what to put in that list.

          -----Original Message-----
          From:   Rosen, Brian [SMTP:brosen@fore.com]
          Sent:   Tuesday, January 11, 2000 2:09 PM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]; = megaco@standards.nortelnetworks.com
          Subject:       = RE: Packages Supported By A = Termination

          Statistics, that's a = good reason.=A0 Let's decide - we will have RTP and ATM packages
          they will have at = least statistics in them.=A0 An audit would tell you that you can = create
          the appropriate = ephemeral.
          =A0
          The question = remains, does a package get to define extensions to SDP and Annex = C?
          Does the original = Annex C have ATM and RTP things in it?=A0 Does the original
          document have any = SDP extensions for ATM?=A0 NetType is found in both Annex C
          and SDP.=A0 In SDP = we need to have the specifics, but the place to put it is in the = SDP,
          and not in = LocalControl, right?=A0 Same with addrtype.=A0 So if a package could = define
          extensions to Annex = C and SDP, then you could define the ATM extensions to
          SDP in the ATM = package.=A0 I'm not sure we want to allow such a thing.
          =A0
          I'm still mystified = what problem you see auditing.=A0 If you have an ephemeral,=20
          an audit will tell = you what packages it implements.=A0=20
          =A0=A0=A0 = AuditValue=3DRTPxxxxx{Audit{Packages}}
          returns the list of = packages implemented on the ephemeral RTPxxxxx
          =A0
          Brian.

            -----Original Message-----
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
            Sent: Tuesday, January 11, 2000 1:58 PM
            To: Rosen, Brian; megaco@standards.nortelnetworks.com
            Subject: RE: Packages Supported By A Termination

            Basically you need = at least three items in an ATM package that I can think of off the top = of my head: the nettype and addrtype extensions to SDP, means to = specify all the ATM-related parameters (darned if I know how -- SDP = attributes generally seem to be associated with codecs, not bearers), = and ATM-specific statistics.=A0 I can't think of any need for an IP = package at this point -- we would collect statistics at a higher level = (RTP, whatever is inherent in an alternative encapsulation), and SDP = doesn't need extending to handle it.=A0 We do need to extend SDP to = handle TCP transport.

            It's all very well = to say that the MG will support ephemeral terminations with this = package or that package, but once an ephemeral has been instantiated, = how will an audit determine the contents of the package list for that = specific termination?=A0 I believe it will do it as I say, by inferring = it from the termination's current properties.

                    -----Original Message-----
            From:=A0=A0 Rosen, Brian = [SMTP:brosen@fore.com]
            Sent:=A0=A0 Tuesday, January = 11, 2000 1:38 PM
            To:=A0=A0=A0=A0 Taylor, Tom-PT = [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
            Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Packages = Supported By A Termination

                    We have not determined if there is a package associated = with
            ATM (or IP), and what it needs to = have in it.=A0 Right at the
            moment, unless the package defines = extensions to Annex C and
            SDP, I don't think it has any = purpose.

                    If there are such packages, then the audit of packages = tells
            you that you can order up a bearer = of that type.

                    We have not discussed what audit of local does, but = presumably it
            gives you what the MG could accept = as SDP/Annex C.=A0 In that case
            such an audit would tell you what = types of ephemerals you
            can ask for.

                    We certainly don't need anything else.

                    Brian

                    > -----Original Message-----
            > From: Tom-PT Taylor = [ <mailto:taylor@nortelnetworks.c= om>]
            > Sent: Tuesday, January 11, = 2000 11:18 AM
            > To: = MEGACO@standards.nortelnetworks.com
            > Subject: Re: Packages = Supported By A Termination
            >
            >
            > If the MGC orders up an ephemeral = termination, the stack
            > (whether ATM or IP
            > based) supported by that = termination is determined by the session
            > descriptions in Local and = Remote -- it's not pre-provisioned.
            >
            > > -----Original = Message-----
            > > From: Rosen, Brian = [SMTP:brosen@fore.com]
            > > Sent: Tuesday, January = 11, 2000 11:08 AM
            > > To:=A0=A0 Taylor, Tom-PT = [CAR:B904:EXCH];
            > = MEGACO@standards.nortelnetworks.com
            > > Subject:=A0=A0=A0=A0=A0 = RE: Packages Supported By A Termination
            > >
            > > I don't understand = this.
            > >
            > > The packages realized by = a termination is fixed, mostly at
            > > design time, possibly = altered by provisioning.=A0 There isn't
            > > anything you can = "set".=A0 Auditing to find out what packages
            > > are implemented is = there.=A0 It's the "package list" you
            > > asked for.
            > >
            > > Brian
            > >
            > > > -----Original = Message-----
            > > > From: Tom-PT Taylor = [ <mailto:taylor@nortelnetworks.c= om>]
            > > > Sent: Tuesday, = January 11, 2000 11:01 AM
            > > > To: = MEGACO@standards.nortelnetworks.com
            > > > Subject: Packages = Supported By A Termination
            > > >
            > > >
            > > > It has occurred to = me that the means by which a
            > termination becomes
            > > > associated with a = set of packages is quite obscure and
            > > > generally = indirect.
            > > > For instance, = support of specific bearer-type-related
            > packages will be
            > > > inferred from the = nettype and addrtype used in session
            > > > descriptions = within
            > > > the Local and = Remote descriptors.=A0 Support of a DTMF
            > package will be
            > > > inferred from the = use of DTMF events or signals in the respective
            > > > = descriptors.
            > > >
            > > > Is this how people = see the relationship between packages and
            > > > terminations = in
            > > > general, or do we = need a more specific method of specifying
            > > > support, such = as
            > > > a package list in = TerminationState?=A0 (Note that Package
            > Descriptor is
            > > > returned from = audits, but cannot be set.)
            > > >
            > > > Tom = Taylor
            > > > Advisor -- = IPConnect Standards
            > > > E-mail: = taylor@nortelnetworks.com (internally, Tom-PT Taylor)
            > > > Phone and FAX: +1 = 613 736 0961
            > > >
            >=20

        ------_=_NextPart_001_01BF5C6B.9D8EFAB4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 16:10:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21280 for ; Tue, 11 Jan 2000 16:10:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA7E6690@standards.nortelnetworks.com>; Tue, 11 Jan 2000 15:59:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118756 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 15:57:50 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C6248E0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 15:57:50 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id NAA01992; Tue, 11 Jan 2000 13:07:36 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000111151144.00ac4a00@dogwood.cisco.com> Date: Tue, 11 Jan 2000 15:57:27 -0500 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 09:43 PM 1/10/00 -0500, Tom-PT Taylor wrote: >This is a timely intervention. Before sending the requirements off to the >IESG I wanted to do one last check of the archives. I found a great deal >of responsiveness to Matt's concerns, but not complete capitulation. I >think the proof of the wisdom of these requirements will be found in the >packages which emerge to meet them. In any event we aren't going to be >held up in the way Matt feared. I am therefore going to send the >requirements document in to the IESG as it stands. > >What follows is totally optional reading, but might make sense out of past >debates. > >Fundamentally, I think we are all agreed (including Matt) that Megaco must >work within the following logical control architectures: I agree that we should support item 1. This would allow current NASes to operate most similarly with today's operation. I see item 2 as a subset of item 1 and as such has no further affect on megaco. It does require the MGC to act as a AAA proxy and support the capabilities required thereof, but that is independent of megaco. See comments below: >(1) NAS connects directly to AAA > > > +-------+ +-------+ > > Signaling | | | | > > -----------+ MGC + | AAA | > > | | | server| > > +---+---+ +--+----+ > > | Megaco / > > | / > > +---+---+ / > > | | AAA / > > | NAS +------/ > > | | > > +-------+ > > > >(2) MGC proxies AAA > > > +-------+ +-------+ > > Signaling | | AAA | | > > -----------+ MGC +--------| AAA | > > | | | server| > > +-+-+---+ +--+----+ > > Megaco| |AAA > > | | > > +-+-+---+ > > | | > > | NAS | > > | | > > +-------+ > > > >The first case places the requirement on Megaco to be able to transport >anything which could be received in or derived from call signalling which >is needed for NAS operation, in addition to local policy. The second case >is the same as the first case if the NAS initiates the AAA transaction. Agreed. >The second case introduces novel elements if the MGC is the one to >initiate the query to the AAA server. There are two possibilities, both >of which have their challenges: > >(1) The response leg of the AAA transaction is passed through to the NAS >using an existing AAA protocol. In this case Megaco has to have the means >to tell the NAS that this information is coming, and to allow the NAS to >correlate it with the related Megaco transactions. The correlating >information clearly depends on the particular AAA protocol being used, so >we can look forward to separate packages corresponding to the respective >protocols. Goutam has suggested, I believe, the alternative that >correlation is achieved by proximity, by tunneling the AAA protocol within >the confines of a Megaco command. > > >(2) The response leg of the AAA transaction is translated to a Megaco >equivalent. This leads to the bottomless swamp of protocol duplication >Matt warns about, except that it may not be necessary to pass everything >in the AAA response down to the NAS. Some information may go no further >than the MGC. This approach seems to be implicit in some of the >requirements Nancy has defended. I believe one of the main points has been missed in the summarization. Existing AAA protocols (e.g., RADIUS, TACACS+), provide services for Authentication (are you who you say you are), Authorization (what services are you allowed access to) and Accounting (what happened :-). Traditionally this was done based on the login information from the dialin user (PAP, CHAP, async login). However, with the advent of ISDN more information was available at call setup time to make decisions (e.g., Calling party number, Called Party Number). There were two concurrent trends. Vendors found it convenient to download configuration information at the time of Authentication and/or Authorization. Vendors also found it convenient to use the call setup info to key on certain information. Several of the people who originally developed RADIUS repeatedly stressed that RADIUS was not intended to be a configuration protocol. However, the convenience of using it as such was too great. Therefore, more and more configuration was added to RADIUS. Thus, configuration has erroneously (IMO) been lumped into the term AAA. Current NASes (not all) in dialup networks today can be configured to do two RADIUS accesses. The first is done during Call Setup and is based on Calling or Called Party Number to return some relevant information (e.g., L2TP tunnel info, AAA server info, etc.) The second is based on the username/password acquired during LCP negotiation to do AAA (plus further configuration such as returning an IP address to use for the connection). In an MGC/NAS architecture, the MGC can handle the Call Setup configuration information based on the Calling Party Number, Calling Party Number, CIC or some other info. This is not much different from what it does for Voice. The MGC can store the configuration locally or use LDAP, RADIUS or TACACS+ to access an external server. Whatever way it chooses, the MGC must then be able to send the configuration information to the NAS so the NAS can connect the call and treat it appropriately. After the NAS connects the call and performs LCP negotiation, it will perform AAA normally using RADIUS or whatever protocol the AAA group comes up with. Chip >-----Original Message----- From: Goutam Shaw >[SMTP:goutam.shaw@BRIDGEWATERSYS.COM] Sent: Monday, January 10, 2000 >6:11 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: >I-D ACTION:draft-ietf-megaco-reqs-09.txt > >Nancy, I'm sorry for the delayed reply. I thought we had put this matter >to rest once and for all after we had the conf. call that was attended by >Nancy, Myself, Matt and I think Gunner. According to my opinion what we >have in the requirements is not AAA. These are configuration parameters >that are call specific and have to be conveyed to the MG before the call >is terminated and SHOULD NOT AND CANNOT BE dealt by a AAA server. The >parameter should help determine how the call is supposed to be treated and >has nothing to with "AAA". I would like to keep section d (of >draft-ietf-megaco-reqs-10.txt) as it is, that relates to the ability to >configure the call adaptation rate. For example, for a given call a >service provider might want to restrict the call to 28.8 kbps based on the >call specific policy information. As Tom has mentioned we don't need a >unanimous decision all we need is a consensus and I believe we have it >(unless I hear any major objection from the mailing list which I haven't >heard in the past on this topic). Regards, ..Goutam. Nancy-M Greene wrote: > Matt, Megaco/H.248 is a device control protocol. It is true that for > NAS, we allow the MG itself to contact the AAA server. Yet, there will be > implementations that would have the MGC contact the AAA server. The > requirements in this section allow for the development of a NAS package > IN THE FUTURE, that would allow the information returned from the AAA > server to be passed down to the MG. How this package would be written is > NOT specified in this requirements document. As for your comment that > ALL your comments regarding the NAS section have been ignored, this is > simply not true! Your comments have been discussed several times on the > mailing list. As editor, I have tried to come up with compromise text > again and again, and every time, you come back saying I haven't yet > succeeded in satisfying your wishes. Perhaps it is time for the chair to > step in and see if we have rough consensus on the requirements document > or not. Your comment on 11.2.1 D is correct. 11.2.1 D will be removed > from the requirements document. Also, I don't understand your comment > that the requirements document should change, based on recent discussions > of the protocol. We did update the requirements document based on > discussion at the Washington meeting. Tom is planning to put out a > companion I-D that maps the Megaco/H.248 protocol against the > requirements document. Nancy > -------------------------------------------------------------------------- > Nancy M. Greene Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) > E:ngreene@nortelnetworks.com ---------- From: Matt > Holdrege[SMTP:matt@ASCEND.COM] Sent: Thursday, December 23, 1999 12:00 > PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D > ACTION:draft-ietf-megaco-reqs-09.txt It's sad to see that all my > comments regarding the NAS section have been ignored again. So let's go > through them one more time and I'll try to put more detail into my > comments. At a high level, NAS requirements should be set by the > NAS requirements working group. That's where the experts are. Also, it's > easy to see that there are NO specific NAS requirements for MEGACO. For > the basic purposes of MEGACO, a NAS is no different than a VoIP gateway. > I can see how you may want to do some special things with special > packages, but nothing in the base protocol needs to be NAS > specific. So let's go through the NAS requirements step by > step... A. Callback. This is all that's listed. There are many > aspects to callback which are covered by RADIUS and are a part of the new > AAA requirements. If all you can list is callback, you should remove this > requirement and leave it up to AAA where it belongs. B. Modem > types. This is also handled by RADIUS and AAA. The MG contacts the AAA > server to instruct it on which modem to use. Remember that the MGC and MG > are not necessarily in the same management domain. But the MG DOES trust > it's AAA server. So that is where the information must come from and it > works best if it is transmitted directly. If you introduce a proxy, you > introduce a lot of difficulties. The AAA WG is trying to deal with the > difficulties of proxy and we shouldn't jump ahead of them. C. D. > E. F. These requirements can and should be covered by a single sentence. > The Protocol must be able to support Q.931 IE's. F already kind of says > this. Please be succint and less tutorial. Q.931 IE's are a basic > requirement of all MG's. Not just NAS's. >g. Ability for the > MGC to direct the NAS to connect to a specific tun- > nel, for > example to an LNS, or to an AAA server. There are a multitude of > tunnel types on the Internet. L2TP, IPsec, IPinIP, IPSRA, RSIP, GRE, > PPTP, ATMP, etc. These tunnel types are not all the same. They are > handled in different IETF working groups that have defined their > operation and their setup. The MEGACO WG should not be dictating how > tunnels get set up. Working groups such as L2TPEXT have defined RADIUS to > setup their tunnels. H. This is already covered in the VoIP > section. Reproducing requirements is just adding confusion. You > mention that wiretapping has been removed, yet it is still in 11.2.1 D. > Whether the MEGACO protocol allows wiretap or not, I don't think we want > this specific requirement in an RFC. This was discussed at the Washington > plenary. Lastly, I think this document should go through a more > lengthy last call since we are in the holiday time. We've gone into > detail at the last two meetings on the protocol itself and this > requirements document doesn't accurately reflect that. At 09:41 > AM 12/10/99 -0500, Tom-PT Taylor wrote: >I propose WG Last Call > based on this document, with the expiry two weeks >hence (24 > December). > >Changes from the previous version are as follows: > >- > removed reqt 5.6 c) Support general test capabilities, for > example >loopbacks through the MG to test DSP operation. >It was agreed > that inward loopbacks are outside the scope of the protocol >- they are > not part of call control, so would be handled by some other >maintenance > protocol. Thus the above requirement is deleted. > >- reqt 5.7 a) - > changed word call to connection > >- table in section 11 - > removed wiretap > >- reqt 11.1.3.1 a) rewording of 2nd bullet on > addressing - didn't mean >wildcarding, meant instead allowing the gateway > to choose (part of) the >identifier > >The references need to be > completed still, and there may be an editor's >note or two that should > still come out. >-----Original > Message----- From: > Internet-Drafts@IETF.ORG >[SMTP:Internet-Drafts@IETF.ORG] Sent: > Friday, December 10, 1999 > 8:08 >AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: > I-D >ACTION:draft-ietf-megaco-reqs-09.txt > >A New Internet-Draft is > available from the on-line Internet-Drafts >directories. This draft is a > work item of the Media Gateway Control >Working Group of the > IETF. > > Title : Media Gateway control protocol > architecture > > and requirements Author(s) : > N. > Greene, M. Ramalho, B. Rosen Filename : > > draft-ietf-megaco-reqs-09.txt Pages : > > 45 Date : 09-Dec-99 > >TThis document describes > protocol requirements for the Media Gateway >control protocol between a > Media Gateway Controller and a Media Gateway. A >URL for this > Internet-Draft >is: >< > <http:/ > /www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>> > >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > >I > nternet-Drafts are also available by anonymous FTP. Login with > the >username "anonymous" and a password of your e-mail address. After > logging >in, type "cd internet-drafts" and > then "get >draft-ietf-megaco-reqs-09.txt". > >A list of > Internet-Drafts directories can be found >in < > <http://www.ietf.org/shadow.html>> > or >< > <ftp://ftp.ietf.org/ietf/1shado > w-sites.txt>> > >sites.txt > >Internet-Drafts can also > be obtained by e-mail. > >Send a message > to: mailserv@ietf.org. In the body >type: "FILE > /internet-drafts/draft-ietf-megaco-reqs-09.txt". > >NOTE: The mail > server at ietf.org can return the document >in MIME-encoded form > by using the "mpack" utility. To use >this feature, insert the > command "ENCODING mime" before the >"FILE" command. To decode > the response(s), you will need >"munpack" or a MIME-compliant > mail reader. Different >MIME-compliant mail readers exhibit > different behavior, >especially when dealing with "multipart" > MIME messages (i.e. >documents which have been split up into > multiple messages), so >check your local documentation on how to > manipulate these messages. > >Below is the data which will enable a MIME > compliant mail >reader implementation to automatically retrieve the > ASCII version of >the Internet-Draft. << Message: >> > << File: Card for Goutam Shaw >> Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 11 16:15:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21381 for ; Tue, 11 Jan 2000 16:15:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A9DB1E0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 16:03:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 118774 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 11 Jan 2000 16:02:35 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44ECF3C0@standards.nortelnetworks.com>; Tue, 11 Jan 2000 16:02:32 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 11 Jan 2000 15:12:40 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 11 Jan 2000 16:12:11 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Tue, 11 Jan 2000 16:12:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5C78.84630118" Message-ID: Date: Tue, 11 Jan 2000 16:12:04 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5C78.84630118 Content-Type: text/plain; charset="iso-8859-1" Thanks for that explanation. It accords with our current set of requirements and can be used to guide definition of the packages required to implement them. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Tuesday, January 11, 2000 3:57 PM > To: Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt > > At 09:43 PM 1/10/00 -0500, Tom-PT Taylor wrote: > > >This is a timely intervention. Before sending the requirements off to > the > >IESG I wanted to do one last check of the archives. I found a great deal > > >of responsiveness to Matt's concerns, but not complete capitulation. I > >think the proof of the wisdom of these requirements will be found in the > >packages which emerge to meet them. In any event we aren't going to be > >held up in the way Matt feared. I am therefore going to send the > >requirements document in to the IESG as it stands. > > > >What follows is totally optional reading, but might make sense out of > past > >debates. > > > >Fundamentally, I think we are all agreed (including Matt) that Megaco > must > >work within the following logical control architectures: > > I agree that we should support item 1. This would allow current NASes to > operate most similarly with today's operation. > > I see item 2 as a subset of item 1 and as such has no further affect on > megaco. It does require the MGC to act as a AAA proxy and support the > capabilities required thereof, but that is independent of megaco. > > See comments below: > > > >(1) NAS connects directly to AAA > > > > > +-------+ +-------+ > > > Signaling | | | | > > > -----------+ MGC + | AAA | > > > | | | server| > > > +---+---+ +--+----+ > > > | Megaco / > > > | / > > > +---+---+ / > > > | | AAA / > > > | NAS +------/ > > > | | > > > +-------+ > > > > > > >(2) MGC proxies AAA > > > > > +-------+ +-------+ > > > Signaling | | AAA | | > > > -----------+ MGC +--------| AAA | > > > | | | server| > > > +-+-+---+ +--+----+ > > > Megaco| |AAA > > > | | > > > +-+-+---+ > > > | | > > > | NAS | > > > | | > > > +-------+ > > > > > > >The first case places the requirement on Megaco to be able to transport > >anything which could be received in or derived from call signalling which > > >is needed for NAS operation, in addition to local policy. The second > case > >is the same as the first case if the NAS initiates the AAA transaction. > > Agreed. > > > >The second case introduces novel elements if the MGC is the one to > >initiate the query to the AAA server. There are two possibilities, both > >of which have their challenges: > > > >(1) The response leg of the AAA transaction is passed through to the NAS > >using an existing AAA protocol. In this case Megaco has to have the > means > >to tell the NAS that this information is coming, and to allow the NAS to > >correlate it with the related Megaco transactions. The correlating > >information clearly depends on the particular AAA protocol being used, so > > >we can look forward to separate packages corresponding to the respective > >protocols. Goutam has suggested, I believe, the alternative that > >correlation is achieved by proximity, by tunneling the AAA protocol > within > >the confines of a Megaco command. > > > > > >(2) The response leg of the AAA transaction is translated to a Megaco > >equivalent. This leads to the bottomless swamp of protocol duplication > >Matt warns about, except that it may not be necessary to pass everything > >in the AAA response down to the NAS. Some information may go no further > >than the MGC. This approach seems to be implicit in some of the > >requirements Nancy has defended. > > I believe one of the main points has been missed in the summarization. > > Existing AAA protocols (e.g., RADIUS, TACACS+), provide services for > Authentication (are you who you say you are), Authorization (what services > > are you allowed access to) and Accounting (what happened > :-). Traditionally this was done based on the login information from the > dialin user (PAP, CHAP, async login). However, with the advent of ISDN > more information was available at call setup time to make decisions (e.g., > > Calling party number, Called Party Number). > > There were two concurrent trends. Vendors found it convenient to download > > configuration information at the time of Authentication and/or > Authorization. Vendors also found it convenient to use the call setup > info > to key on certain information. > > Several of the people who originally developed RADIUS repeatedly stressed > that RADIUS was not intended to be a configuration protocol. However, the > > convenience of using it as such was too great. Therefore, more and more > configuration was added to RADIUS. Thus, configuration has erroneously > (IMO) been lumped into the term AAA. > > Current NASes (not all) in dialup networks today can be configured to do > two RADIUS accesses. > > The first is done during Call Setup and is based on Calling or Called > Party > Number to return some relevant information (e.g., L2TP tunnel info, AAA > server info, etc.) > > The second is based on the username/password acquired during LCP > negotiation to do AAA (plus further configuration such as returning an IP > address to use for the connection). > > In an MGC/NAS architecture, the MGC can handle the Call Setup > configuration > information based on the Calling Party Number, Calling Party Number, CIC > or > some other info. This is not much different from what it does for > Voice. The MGC can store the configuration locally or use LDAP, RADIUS or > > TACACS+ to access an external server. Whatever way it chooses, the MGC > must then be able to send the configuration information to the NAS so the > NAS can connect the call and treat it appropriately. > > After the NAS connects the call and performs LCP negotiation, it will > perform AAA normally using RADIUS or whatever protocol the AAA group comes > > up with. > > Chip > > >-----Original Message----- From: Goutam Shaw > >[SMTP:goutam.shaw@BRIDGEWATERSYS.COM] Sent: Monday, January 10, 2000 > >6:11 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: > > >I-D ACTION:draft-ietf-megaco-reqs-09.txt > > > >Nancy, I'm sorry for the delayed reply. I thought we had put this matter > >to rest once and for all after we had the conf. call that was attended by > > >Nancy, Myself, Matt and I think Gunner. According to my opinion what we > >have in the requirements is not AAA. These are configuration parameters > >that are call specific and have to be conveyed to the MG before the call > >is terminated and SHOULD NOT AND CANNOT BE dealt by a AAA server. The > >parameter should help determine how the call is supposed to be treated > and > >has nothing to with "AAA". I would like to keep section d (of > >draft-ietf-megaco-reqs-10.txt) as it is, that relates to the ability to > >configure the call adaptation rate. For example, for a given call a > >service provider might want to restrict the call to 28.8 kbps based on > the > >call specific policy information. As Tom has mentioned we don't need a > >unanimous decision all we need is a consensus and I believe we have it > >(unless I hear any major objection from the mailing list which I haven't > >heard in the past on this topic). Regards, ..Goutam. Nancy-M Greene > wrote: > > Matt, Megaco/H.248 is a device control protocol. It is true that for > > NAS, we allow the MG itself to contact the AAA server. Yet, there will > be > > implementations that would have the MGC contact the AAA server. The > > requirements in this section allow for the development of a NAS package > > IN THE FUTURE, that would allow the information returned from the AAA > > server to be passed down to the MG. How this package would be written is > > > NOT specified in this requirements document. As for your comment that > > ALL your comments regarding the NAS section have been ignored, this is > > simply not true! Your comments have been discussed several times on the > > mailing list. As editor, I have tried to come up with compromise text > > again and again, and every time, you come back saying I haven't yet > > succeeded in satisfying your wishes. Perhaps it is time for the chair > to > > step in and see if we have rough consensus on the requirements document > > or not. Your comment on 11.2.1 D is correct. 11.2.1 D will be removed > > from the requirements document. Also, I don't understand your comment > > that the requirements document should change, based on recent > discussions > > of the protocol. We did update the requirements document based on > > discussion at the Washington meeting. Tom is planning to put out a > > companion I-D that maps the Megaco/H.248 protocol against the > > requirements document. Nancy > > > -------------------------------------------------------------------------- > > > Nancy M. Greene Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) > > E:ngreene@nortelnetworks.com ---------- From: Matt > > Holdrege[SMTP:matt@ASCEND.COM] Sent: Thursday, December 23, 1999 12:00 > > PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D > > ACTION:draft-ietf-megaco-reqs-09.txt It's sad to see that all my > > > comments regarding the NAS section have been ignored again. So let's go > > through them one more time and I'll try to put more detail into my > > comments. At a high level, NAS requirements should be set by > the > > NAS requirements working group. That's where the experts are. Also, it's > > > easy to see that there are NO specific NAS requirements for MEGACO. For > > the basic purposes of MEGACO, a NAS is no different than a VoIP gateway. > > > I can see how you may want to do some special things with special > > packages, but nothing in the base protocol needs to be NAS > > specific. So let's go through the NAS requirements step by > > step... A. Callback. This is all that's listed. There are many > > aspects to callback which are covered by RADIUS and are a part of the > new > > AAA requirements. If all you can list is callback, you should remove > this > > requirement and leave it up to AAA where it belongs. B. Modem > > types. This is also handled by RADIUS and AAA. The MG contacts the AAA > > server to instruct it on which modem to use. Remember that the MGC and > MG > > are not necessarily in the same management domain. But the MG DOES trust > > > it's AAA server. So that is where the information must come from and it > > works best if it is transmitted directly. If you introduce a proxy, you > > introduce a lot of difficulties. The AAA WG is trying to deal with the > > difficulties of proxy and we shouldn't jump ahead of them. C. > D. > > E. F. These requirements can and should be covered by a single sentence. > > > The Protocol must be able to support Q.931 IE's. F already kind of says > > this. Please be succint and less tutorial. Q.931 IE's are a basic > > requirement of all MG's. Not just NAS's. >g. Ability for the > > > MGC to direct the NAS to connect to a specific tun- > nel, for > > example to an LNS, or to an AAA server. There are a multitude > of > > tunnel types on the Internet. L2TP, IPsec, IPinIP, IPSRA, RSIP, GRE, > > PPTP, ATMP, etc. These tunnel types are not all the same. They are > > handled in different IETF working groups that have defined their > > operation and their setup. The MEGACO WG should not be dictating how > > tunnels get set up. Working groups such as L2TPEXT have defined RADIUS > to > > setup their tunnels. H. This is already covered in the VoIP > > section. Reproducing requirements is just adding confusion. You > > > mention that wiretapping has been removed, yet it is still in 11.2.1 D. > > Whether the MEGACO protocol allows wiretap or not, I don't think we want > > > this specific requirement in an RFC. This was discussed at the > Washington > > plenary. Lastly, I think this document should go through a more > > > lengthy last call since we are in the holiday time. We've gone into > > detail at the last two meetings on the protocol itself and this > > requirements document doesn't accurately reflect that. At 09:41 > > > AM 12/10/99 -0500, Tom-PT Taylor wrote: >I propose WG Last Call > > > based on this document, with the expiry two weeks >hence (24 > > December). > >Changes from the previous version are as follows: > >- > > removed reqt 5.6 c) Support general test capabilities, for > > example >loopbacks through the MG to test DSP operation. >It was agreed > > that inward loopbacks are outside the scope of the protocol >- they are > > not part of call control, so would be handled by some other >maintenance > > > protocol. Thus the above requirement is deleted. > >- reqt 5.7 a) - > > changed word call to connection > >- table in section 11 - > > removed wiretap > >- reqt 11.1.3.1 a) rewording of 2nd bullet on > > addressing - didn't mean >wildcarding, meant instead allowing the > gateway > > to choose (part of) the >identifier > >The references need to be > > completed still, and there may be an editor's >note or two that should > > still come out. >-----Original > > Message----- From: > > Internet-Drafts@IETF.ORG >[SMTP:Internet-Drafts@IETF.ORG] Sent: > > Friday, December 10, 1999 > > 8:08 >AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: > > I-D >ACTION:draft-ietf-megaco-reqs-09.txt > >A New Internet-Draft is > > available from the on-line Internet-Drafts >directories. This draft is > a > > work item of the Media Gateway Control >Working Group of the > > IETF. > > Title : Media Gateway control protocol > > architecture > > > and requirements Author(s) : > > N. > Greene, M. Ramalho, B. Rosen Filename : > > > draft-ietf-megaco-reqs-09.txt Pages : > > > 45 Date : 09-Dec-99 > >TThis document describes > > protocol requirements for the Media Gateway >control protocol between a > > Media Gateway Controller and a Media Gateway. A >URL for this > > Internet-Draft >is: >< > > > <http:/ > > > /www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>> > > >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > > >I > > nternet-Drafts are also available by anonymous FTP. Login with > > the >username "anonymous" and a password of your e-mail address. After > > logging >in, type "cd internet-drafts" and > > then "get >draft-ietf-megaco-reqs-09.txt". > >A list of > > Internet-Drafts directories can be found >in < > > <http://www.ietf.org/shadow.html>> > > or >< > > > <ftp://ftp.ietf.org/ietf/1shado > > > w-sites.txt>> > > >sites.txt > >Internet-Drafts can > also > > be obtained by e-mail. > >Send a message > > to: mailserv@ietf.org. In the body >type: "FILE > > /internet-drafts/draft-ietf-megaco-reqs-09.txt". > >NOTE: The mail > > server at ietf.org can return the document >in MIME-encoded > form > > by using the "mpack" utility. To use >this feature, insert the > > > command "ENCODING mime" before the >"FILE" command. To decode > > the response(s), you will need >"munpack" or a MIME-compliant > > mail reader. Different >MIME-compliant mail readers exhibit > > different behavior, >especially when dealing with "multipart" > > MIME messages (i.e. >documents which have been split up into > > multiple messages), so >check your local documentation on how > to > > manipulate these messages. > >Below is the data which will enable a MIME > > > compliant mail >reader implementation to automatically retrieve the > > ASCII version of >the Internet-Draft. << Message: >> > > << File: Card for Goutam Shaw >> > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > ------_=_NextPart_001_01BF5C78.84630118 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-reqs-09.txt

        Thanks for that = explanation.  It accords with our current set of requirements and = can be used to guide definition of the packages required to implement = them.

          -----Original Message-----
          From:   Chip Sharp [SMTP:chsharp@cisco.com]
          Sent:   Tuesday, January 11, 2000 3:57 PM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]; = MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = Re: I-D = ACTION:draft-ietf-megaco-reqs-09.txt

          At 09:43 PM 1/10/00 -0500, Tom-PT = Taylor wrote:

          >This is a timely = intervention.  Before sending the requirements off to the
          >IESG I wanted to do one last = check of the archives.  I found a great deal
          >of responsiveness to Matt's = concerns, but not complete capitulation.  I
          >think the proof of the wisdom of = these requirements will be found in the
          >packages which emerge to meet = them.  In any event we aren't going to be
          >held up in the way Matt = feared.  I am therefore going to send the
          >requirements document in to the = IESG as it stands.
          >
          >What follows is totally optional = reading, but might make sense out of past
          >debates.
          >
          >Fundamentally, I think we are all = agreed (including Matt) that Megaco must
          >work within the following logical = control architectures:

          I agree that we should support item = 1.  This would allow current NASes to
          operate most similarly with today's = operation.

          I see item 2 as a subset of  item = 1 and as such has no further affect on
          megaco.  It does require the MGC = to act as a AAA proxy and support the
          capabilities required thereof, but = that is independent of megaco.

          See comments below:


          >(1) NAS connects directly to = AAA
          >
          > = >           &n= bsp;  +-------+        = +-------+
          > >   Signaling  = |       = |        = |       |
          > >   = -----------+  MGC  = +        |  AAA  |
          > = >           &n= bsp;  |       = |        | server|
          > = >           &n= bsp;  +---+---+        = +--+----+
          > = >           &n= bsp;      | = Megaco       /
          > = >           &n= bsp;      = |            = ; /
          > = >           &n= bsp;  +---+---+        /
          > = >           &n= bsp;  |       |   AAA = /
          > = >           &n= bsp;  |  NAS  +------/
          > = >           &n= bsp;  |       |
          > = >           &n= bsp;  +-------+
          > >
          >
          >(2) MGC proxies AAA
          >
          > = >           &n= bsp;  +-------+        = +-------+
          > >   Signaling  = |       |  AAA   = |       |
          > >   = -----------+  MGC  +--------|  AAA  |
          > = >           &n= bsp;  |       = |        | server|
          > = >           &n= bsp;  +-+-+---+        = +--+----+
          > = >          Megaco| = |AAA
          > = >           &n= bsp;    | |
          > = >           &n= bsp;  +-+-+---+
          > = >           &n= bsp;  |       |
          > = >           &n= bsp;  |  NAS  |
          > = >           &n= bsp;  |       |
          > = >           &n= bsp;  +-------+
          > >
          >
          >The first case places the = requirement on Megaco to be able to transport
          >anything which could be received = in or derived from call signalling which
          >is needed for NAS operation, in = addition to local policy.  The second case
          >is the same as the first case if = the NAS initiates the AAA transaction.

          Agreed.


          >The second case introduces novel = elements if the MGC is the one to
          >initiate the query to the AAA = server.  There are two possibilities, both
          >of which have their = challenges:
          >
          >(1) The response leg of the AAA = transaction is passed through to the NAS
          >using an existing AAA = protocol.  In this case Megaco has to have the means
          >to tell the NAS that this = information is coming, and to allow the NAS to
          >correlate it with the related = Megaco transactions.  The correlating
          >information clearly depends on = the particular AAA protocol being used, so
          >we can look forward to separate = packages corresponding to the respective
          >protocols.  Goutam has = suggested, I believe, the alternative that
          >correlation is achieved by = proximity, by tunneling the AAA protocol within
          >the confines of a Megaco = command.
          >
          >
          >(2) The response leg of the AAA = transaction is translated to a Megaco
          >equivalent.  This leads to = the bottomless swamp of protocol duplication
          >Matt warns about, except that it = may not be necessary to pass everything
          >in the AAA response down to the = NAS.  Some information may go no further
          >than the MGC.  This approach = seems to be implicit in some of the
          >requirements Nancy has = defended.

          I believe one of the main points has = been missed in the summarization.

          Existing AAA protocols (e.g., RADIUS, = TACACS+), provide services for
          Authentication (are you who you say = you are), Authorization (what services
          are you allowed access to) and = Accounting (what happened
          :-).  Traditionally this was = done based on the login information from the
          dialin user (PAP, CHAP, async = login).  However, with the advent of ISDN
          more information was available at = call setup time to make decisions (e.g.,
          Calling party number, Called Party = Number).

          There were two concurrent = trends.  Vendors found it convenient to download
          configuration information at the time = of Authentication and/or
          Authorization.  Vendors also = found it convenient to use the call setup info
          to key on certain information.

          Several of the people who originally = developed RADIUS repeatedly stressed
          that RADIUS was not intended to be a = configuration protocol.  However, the
          convenience of using it as such was = too great.  Therefore, more and more
          configuration was added to = RADIUS.  Thus, configuration has erroneously
          (IMO) been lumped into the term = AAA.

          Current NASes  (not all) in = dialup networks today can be configured to do
          two RADIUS accesses.

          The first is done during Call Setup = and is based on Calling or Called Party
          Number to return some relevant = information (e.g., L2TP tunnel info, AAA
          server info, etc.)

          The second is based on the = username/password acquired during LCP
          negotiation to do AAA (plus further = configuration such as returning an IP
          address to use for the = connection).

          In an MGC/NAS architecture, the MGC = can handle the Call Setup configuration
          information based on the Calling = Party Number, Calling Party Number, CIC or
          some other info.  This is not = much different from what it does for
          Voice.  The MGC can store the = configuration locally or use LDAP, RADIUS or
          TACACS+ to access an external = server.  Whatever way it chooses, the MGC
          must then be able to send the = configuration information to the NAS so the
          NAS can connect the call and treat it = appropriately.

          After the NAS connects the call and = performs LCP negotiation, it will
          perform AAA normally using RADIUS or = whatever protocol the AAA group comes
          up with.

          Chip

          >-----Original Message-----  = From:   Goutam Shaw
          >[SMTP:goutam.shaw@BRIDGEWATERSYS.COM]  = Sent:   Monday, January 10, 2000
          >6:11 PM  = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  = Subject:        Re:
          >I-D = ACTION:draft-ietf-megaco-reqs-09.txt
          >
          >Nancy, I'm sorry for the delayed = reply. I thought we had put this matter
          >to rest once and for all after we = had the conf. call that was attended by
          >Nancy, Myself, Matt and I think = Gunner. According to my opinion what we
          >have in the requirements is not = AAA. These are configuration parameters
          >that are call specific and have = to be conveyed to the MG before the call
          >is terminated and SHOULD NOT AND = CANNOT BE dealt by a AAA server. The
          >parameter should help determine = how the call is supposed to be treated and
          >has nothing to with = "AAA". I would like to keep section d (of
          >draft-ietf-megaco-reqs-10.txt)  as it is, that = relates to the ability to
          >configure the call adaptation = rate. For example, for a given call a
          >service provider might want to = restrict the call to 28.8 kbps based on the
          >call specific policy = information.  As Tom has mentioned we don't need a
          >unanimous decision all we need is = a consensus and I believe we have it
          >(unless I hear any major = objection from the mailing list which I haven't
          >heard in the past on this topic). = Regards, ..Goutam. Nancy-M Greene wrote:
          >    Matt, = Megaco/H.248 is a device control protocol. It is true that for
          > NAS, we allow the MG itself to = contact the AAA server. Yet, there will be
          > implementations that would have = the MGC contact the AAA server. The
          > requirements in this section = allow for the development of a NAS package
          > IN THE FUTURE, that would allow = the information returned from the AAA
          > server to be passed down to the = MG. How this package would be written is
          > NOT specified in this = requirements document.  As for your comment that
          > ALL your comments regarding the = NAS section have been ignored, this is
          > simply not true! Your comments = have been discussed several times on the
          > mailing list. As editor, I have = tried to come up with compromise text
          > again and again, and every time, = you come back saying I haven't yet
          > succeeded in satisfying your = wishes.  Perhaps it is time for the chair to
          > step in and see if we have rough = consensus on the requirements document
          > or not.  Your comment on = 11.2.1 D is correct. 11.2.1 D will be removed
          > from the requirements = document.  Also, I don't understand your comment
          > that the requirements document = should change, based on recent discussions
          > of the protocol. We did update = the requirements document based on
          > discussion at the Washington = meeting. Tom is planning to put out a
          > companion I-D that maps the = Megaco/H.248 protocol against the
          > requirements document.  = Nancy
          > = ------------------------------------------------------------------------= --
           >  Nancy M. Greene = Internet & Service Provider Networks, Nortel Networks
          > T:514-271-7221 = (internal:ESN853-1077)
          > = E:ngreene@nortelnetworks.com       &n= bsp; ---------- From:  Matt
          > Holdrege[SMTP:matt@ASCEND.COM] = Sent:  Thursday, December 23, 1999 12:00
          > PM To:    = MEGACO@STANDARDS.NORTELNETWORKS.COM = Subject:       Re: I-D
          > = ACTION:draft-ietf-megaco-reqs-09.txt      =    It's sad to see that all my
          > comments regarding the NAS = section have been ignored again. So let's go
          > through them one more time and = I'll try to put more detail into my
          > = comments.          At a = high level, NAS requirements should be set by the
          > NAS requirements working group. = That's where the experts are. Also, it's
          > easy to see that there are NO = specific NAS requirements for MEGACO. For
          > the basic purposes of MEGACO, a = NAS is no different than a VoIP gateway.
          > I can see how you may want to do = some special things with special
          > packages, but nothing in the = base protocol needs to be NAS
          > = specific.          So = let's go through the NAS requirements step by
          > = step...          A. = Callback. This is all that's listed. There are many
          > aspects to callback which are = covered by RADIUS and are a part of the new
          > AAA requirements. If all you can = list is callback, you should remove this
          > requirement and leave it up to = AAA where it = belongs.          B. Modem =
          > types. This is also handled by = RADIUS and AAA. The MG contacts the AAA
          > server to instruct it on which = modem to use. Remember that the MGC and MG
          > are not necessarily in the same = management domain. But the MG DOES trust
          > it's AAA server. So that is = where the information must come from and it
          > works best if it is transmitted = directly. If you introduce a proxy, you
          > introduce a lot of difficulties. = The AAA WG is trying to deal with the
          > difficulties of proxy and we = shouldn't jump ahead of = them.          C. D. =
          > E. F. These requirements can and = should be covered by a single sentence.
          > The Protocol must be able to = support Q.931 IE's. F already kind of says
          > this. Please be succint and less = tutorial. Q.931 IE's are a basic
          > requirement of all MG's. Not = just NAS's.           = >g.   Ability for the
          > MGC to direct the NAS to connect = to a specific tun-  >     nel, for
          > example to an LNS, or to an AAA = server.          There are = a multitude of
          > tunnel types on the Internet. = L2TP, IPsec, IPinIP, IPSRA, RSIP, GRE,
          > PPTP, ATMP, etc. These tunnel = types are not all the same. They are
          > handled in different IETF = working groups that have defined their
          > operation and their setup. The = MEGACO WG should not be dictating how
          > tunnels get set up. Working = groups such as L2TPEXT have defined RADIUS to
          > setup their = tunnels.          H. This = is already covered in the VoIP
          > section. Reproducing = requirements is just adding = confusion.          You =
          > mention that wiretapping has = been removed, yet it is still in 11.2.1 D.
          > Whether the MEGACO protocol = allows wiretap or not, I don't think we want
          > this specific requirement in an = RFC. This was discussed at the Washington
          > = plenary.          Lastly, = I think this document should go through a more
          > lengthy last call since we are = in the holiday time. We've gone into
          > detail at the last two meetings = on the protocol itself and this
          > requirements document doesn't = accurately reflect = that.          At 09:41 =
          > AM 12/10/99 -0500, Tom-PT Taylor = wrote:          >I = propose WG Last Call
          > based on this document, with the = expiry two weeks >hence (24
          > December). > >Changes from = the previous version are as follows: > >-
          > removed reqt 5.6 c) Support = general test capabilities, for
          > example >loopbacks through = the MG to test DSP operation. >It was agreed
          > that inward loopbacks are = outside the scope of the protocol >- they are
          > not part of call control, so = would be handled by some other >maintenance
          > protocol. Thus the above = requirement is deleted. > >- reqt 5.7 a) -
          > changed word call to connection = > >- table in section 11 -
          > removed  wiretap > >- = reqt 11.1.3.1 a) rewording of 2nd bullet  on
          > addressing - didn't mean = >wildcarding, meant instead allowing the gateway
          > to choose (part of) the = >identifier > >The references need to be
          > completed still, and there may = be an editor's >note or two that should
          > still come out. = >-----Original
          > Message-----  From:
          > Internet-Drafts@IETF.ORG = >[SMTP:Internet-Drafts@IETF.ORG]  Sent:
          > Friday, December 10, 1999 =
          > 8:08 >AM  = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  = Subject:
          > I-D = >ACTION:draft-ietf-megaco-reqs-09.txt > >A New Internet-Draft = is
          > available from the on-line = Internet-Drafts >directories.  This draft is a
          > work item of the Media Gateway = Control >Working Group of the
          > IETF. > = >         = Title           : = Media Gateway control protocol
          > architecture >
          > = and           &nb= sp;           &nb= sp;    = requirements          = Author(s)       :
          > N. > Greene,  M. = Ramalho,  B. = Rosen          = Filename        : >
          > = draft-ietf-megaco-reqs-09.txt       &= nbsp;  = Pages           : = >
          > = 45          = Date            = : 09-Dec-99 > >TThis document describes
          > protocol requirements for the = Media Gateway >control protocol between a
          > Media Gateway Controller and a = Media Gateway. A >URL for this
          > Internet-Draft >is: >< =
          > <<http://www.ietf.org/internet-drafts/draft-ietf-megaco-= reqs-09.txt>http:/ =
          > = /www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt>> =
          > <http://w> = >ww.ietf.org/internet-drafts/draft-ietf-megaco-reqs-09.txt > = >I
          > nternet-Drafts are also = available by anonymous FTP. Login with
          > the >username  = "anonymous" and a password of your e-mail address. After =
          > logging >in,  type = "cd internet-drafts" and
          > = then          "get = >draft-ietf-megaco-reqs-09.txt". > >A list of
          > Internet-Drafts directories can = be found >in  <
          > <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html>>
          > <http://www.ietf.org/shadow.html>  or ><
          > <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shado
          > w-sites.txt>>
          > <ftp://ftp.ietf.org/ietf/1shadow-> >sites.txt > >Internet-Drafts can = also
          > be obtained by e-mail. > = >Send a message
          > = to:          = mailserv@ietf.org.  In the body = >type:          = "FILE
          > = /internet-drafts/draft-ietf-megaco-reqs-09.txt". > = >NOTE:   The mail
          > server at ietf.org can return = the document = >in          = MIME-encoded form
          > by using the "mpack" = utility.  To use = >this          feature, = insert the
          > command "ENCODING = mime" before the = >"FILE"        &nbs= p; command.  To decode
          > the response(s), you will need = >"munpack" = or          a = MIME-compliant
          > mail reader.  Different = >MIME-compliant mail = readers          exhibit =
          > different behavior, = >especially when dealing = with          = "multipart"
          > MIME messages (i.e. = >documents which have been = split          up into =
          > multiple messages), so >check = your local documentation = on          how to
          > manipulate these messages. > = >Below is the data which will enable a MIME
          > compliant mail >reader  = implementation to automatically retrieve the
          > ASCII version of >the  = Internet-Draft. << Message:  >>
          >  << File: Card for = Goutam Shaw >>

          Support NetAid!  http://www.netaid.org
          --------------------------------------------------=
          Chip = Sharp           &= nbsp;     Consulting Engineering
          Cisco = Systems           = ;   Telco Bio-region
          Reality - Love it or Leave it.  =         =        
          --------------------------------------------------=

        ------_=_NextPart_001_01BF5C78.84630118-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 01:07:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28358 for ; Wed, 12 Jan 2000 01:06:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C2493D20@standards.nortelnetworks.com>; Wed, 12 Jan 2000 0:55:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119417 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 00:55:18 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1940C30@standards.nortelnetworks.com>; Wed, 12 Jan 2000 0:55:17 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id VAA07410; Tue, 11 Jan 2000 21:59:53 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 12 Jan 2000 06:05:54 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id WAA16653; Tue, 11 Jan 2000 22:05:53 -0800 (PST) Received: from ascend.com by ascend.com X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000111215650.00ad7100@porky> Date: Tue, 11 Jan 2000 22:06:21 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.2.2.20000111151144.00ac4a00@dogwood.cisco.com> At 03:57 PM 1/11/00 -0500, Chip Sharp wrote: >There were two concurrent trends. Vendors found it convenient to download >configuration information at the time of Authentication and/or >Authorization. Vendors also found it convenient to use the call setup info >to key on certain information. It had nothing to do with vendor convenience. It has to do with ISP demand. That's the way that the vast majority of ISP's choose to run their operation. >After the NAS connects the call and performs LCP negotiation, it will >perform AAA normally using RADIUS or whatever protocol the AAA group comes >up with. That's where problems can occur. Some of those tricky config paramters must be performed DURING the LCP phase. So you have to have them all lined up in advance. The big problem with this MEGACO proposal is that the real world of Internet Access is much, much more complex that anything written in an RFC. RADIUS has evolved quite a bit to support that complexity. Nothing written in any MEGACO draft comes close to meeting true ISP requirements. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 08:09:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14680 for ; Wed, 12 Jan 2000 08:09:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B5FC94A0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 7:57:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 119978 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 07:56:05 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.739C64A0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 7:55:54 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA13660 for ; Wed, 12 Jan 2000 19:04:48 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256864.00477753 ; Wed, 12 Jan 2000 18:30:36 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256864.0047763A.00@sandesh.hss.hns.com> Date: Wed, 12 Jan 2000 18:33:51 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Service Change for Ephemeral terminations. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi brian, list I have a small query. The service change command is exchanged between MG and MGC to bring and take terminations out of service. Does this indicate that when its generated it implies only for the physical terminations? Assuming a scenario where from a set of IP addresses at MG, one of the IP address is rendered unusable (due to say hardware failure). How will this be indicated from MG to MGC using MEGACO? Such an indication may be required in case where, MGC specifies IP address and port numbers for ephemeral terminations. regards Madhubabu Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 08:18:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15005 for ; Wed, 12 Jan 2000 08:18:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE06B310@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:06:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120049 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 08:05:47 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D547F1A0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:05:47 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 07:14:50 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 12 Jan 2000 08:14:37 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 08:14:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5CFE.F8FD1F50" Message-ID: Date: Wed, 12 Jan 2000 08:14:34 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D ACTION:draft-ietf-megaco-reqs-09.txt X-To: Matt Holdrege To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5CFE.F8FD1F50 Content-Type: text/plain > -----Original Message----- > From: Matt Holdrege [SMTP:matt@ASCEND.COM] > Sent: Wednesday, January 12, 2000 1:06 AM > [[TomT]] This doesn't really bother me. If someone cares, they will do the work to develop the appropriate packages in detail. If everyone finds that other means are preferable, the item will remain open. > The big problem with this MEGACO proposal is that the real world of > Internet Access is much, much more complex that anything written in an > RFC. > RADIUS has evolved quite a bit to support that complexity. Nothing written > in any MEGACO draft comes close to meeting true ISP requirements. ------_=_NextPart_001_01BF5CFE.F8FD1F50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-reqs-09.txt

          -----Original Message-----
          From:   Matt Holdrege [SMTP:matt@ASCEND.COM]
          Sent:   Wednesday, January 12, 2000 1:06 AM

          [[TomT]]  This doesn't really bother = me.  If someone cares, they will do the work to develop the = appropriate packages in detail.  If everyone finds that other = means are preferable, the item will remain open. 

          The big problem with this MEGACO = proposal is that the real world of
          Internet Access is much, much more = complex that anything written in an RFC.
          RADIUS has evolved quite a bit to = support that complexity. Nothing written
          in any MEGACO draft comes close to = meeting true ISP requirements.

        ------_=_NextPart_001_01BF5CFE.F8FD1F50-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 08:27:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15263 for ; Wed, 12 Jan 2000 08:27:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44D3BDA0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:16:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120079 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 08:15:02 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FD81EB0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:15:02 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 07:24:53 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 12 Jan 2000 08:24:41 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 08:24:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5D00.60F90E42" Message-ID: Date: Wed, 12 Jan 2000 08:24:38 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Service Change for Ephemeral terminations. X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5D00.60F90E42 Content-Type: text/plain It makes good sense to use the ServiceChange command in that case too. I expect you're really looking for a way to provide a bulk notification. One possibility would be to model transmission interfaces such as your NICs as terminations -- something I've suggested before. It would take a package with a couple of properties: - type of interface - list of associated (i.e. supported) terminations The behaviour of terminations supporting this package would be that aside from the above properties the only relevant one is serviceState. > -----Original Message----- > From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM] > Sent: Wednesday, January 12, 2000 8:04 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Service Change for Ephemeral terminations. > > Hi brian, list > I have a small query. The service change command is exchanged between > MG > and MGC to bring and take terminations out of service. Does this indicate > that > when its generated it implies only for the physical terminations? Assuming > a > scenario where from a set of IP addresses at MG, one of the IP address is > rendered unusable (due to say hardware failure). How will this be > indicated from > MG to MGC using MEGACO? Such an indication may be required in case where, > MGC > specifies IP address and port numbers for ephemeral terminations. > > regards > > Madhubabu > Hughes Software Systems. ------_=_NextPart_001_01BF5D00.60F90E42 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Service Change for Ephemeral terminations.

        It makes good sense = to use the ServiceChange command in that case too.  I expect = you're really looking for a way to provide a bulk notification.  = One possibility would be to model transmission interfaces such as your = NICs as terminations -- something I've suggested before.  It would = take a package with a couple of properties:

         - type of = interface
         - list of = associated (i.e. supported) terminations
        The behaviour of = terminations supporting this package would be that aside from the above = properties the only relevant one is serviceState.

          -----Original Message-----
          From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
          Sent:   Wednesday, January 12, 2000 8:04 AM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = Service Change for Ephemeral = terminations.

          Hi brian, list
               I have a = small query. The service change command is exchanged between MG
          and MGC to bring and take = terminations out of service. Does this indicate that
          when its generated it implies only = for the physical terminations? Assuming a
          scenario where from a set of IP = addresses at MG, one of the IP address is
          rendered unusable (due to say = hardware failure). How will this be indicated from
          MG to MGC using MEGACO? Such an = indication may be required in case where, MGC
          specifies IP address and port numbers = for ephemeral terminations.

          regards

          Madhubabu
          Hughes Software Systems.

        ------_=_NextPart_001_01BF5D00.60F90E42-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 08:31:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15400 for ; Wed, 12 Jan 2000 08:31:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4E99310@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:20:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120069 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 08:18:39 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BD1CA90@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:08:39 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA08165; Wed, 12 Jan 2000 08:19:15 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA09392; Wed, 12 Jan 2000 08:19:17 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Jan 2000 08:16:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF06863E@whq-msgusr-02.fore.com> Date: Wed, 12 Jan 2000 08:19:15 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Service Change for Ephemeral terminations. X-To: "bmbabu@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd say that it would be reasonable for the MG to tell the MGC that the ephemerals were out of service with the ServiceChange command. The MGC should respond with Subtracts which will destroy the ephemerals. An interesting question is what else it should do. Generally we have avoided including in the protocol things we deemed to be a "management" or "maintenance" function. The issue here is that if the MGC asks for a new connection, it might get an error. What to do? Take the MG out of service? Suppose there were more than one interface; it isn't necessary to take the whole MG down. I think that this is not a big enough problem to solve now. The answer to the question is yes, use the ServiceChange, the MGC will subtract the ephemerals, and the state between the MG and MGC will be rationalized. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@hss.hns.com] > Sent: Wednesday, January 12, 2000 8:04 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Service Change for Ephemeral terminations. > > > Hi brian, list > I have a small query. The service change command is > exchanged between MG > and MGC to bring and take terminations out of service. Does > this indicate that > when its generated it implies only for the physical > terminations? Assuming a > scenario where from a set of IP addresses at MG, one of the > IP address is > rendered unusable (due to say hardware failure). How will > this be indicated from > MG to MGC using MEGACO? Such an indication may be required in > case where, MGC > specifies IP address and port numbers for ephemeral terminations. > > regards > > Madhubabu > Hughes Software Systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 08:52:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15956 for ; Wed, 12 Jan 2000 08:52:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBE977F0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:41:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120121 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 08:40:17 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5885590@standards.nortelnetworks.com>; Wed, 12 Jan 2000 8:40:14 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 07:50:14 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 12 Jan 2000 08:50:03 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 08:50:02 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 12 Jan 2000 08:49:59 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Digit Map Symbols To: MEGACO@STANDARDS.NORTELNETWORKS.COM Further to this proposal, here are the consequences for our protocol document. This first change comes from an E-mail I sent to our editors, giving my comments on the latest draft: 7.1.14: the full semantics of digit map usage per the ABNF should be explained. Here is my attempt; please correct any errors. It is designed to fit just after the sentence: "Each string in the list is an alternative numbering scheme, specified either as a set of digits or timers, or as a regular expression of digits and timers." Within a string, the digits "0" through "9" and letters "A" through a maximum value depending on the signalling system concerned, but never exceeding "K", correspond to specified events within a package which has been designated in the Events Descriptor on the termination to which the digit map is being applied. (The mapping between events and digit map symbols is defined in the documentation for packages associated with channel-associated signalling systems such as DTMF, MF, or R2. Digits "0" through "9" MUST be mapped to the corresponding digit events within the signalling system concerned. Letters should be allocated in logical fashion, facilitating the use of range notation for alternative events.) The letter "x" is used as a wildcard, designating any event corresponding to symbols in the range "0"-"9". The string may also contain explicit ranges and, more generally, explicit sets of symbols, designating alternative events any one of which satisfies that position of the digit map. In addition to these event symbols, the string may contain "S" and "L" duration modifiers. An "L" designates a long event: placed in front of the symbol(s) designating the event(s) which satisfy a given digit position, it indicates that that position is satisfied only if the duration of the event exceeds the long-duration threshold. The value of this threshold is assumed to be provisioned in the MG. [What is "S" used for???] Optionally, the expression defining the eligible set of events for a given digit position may be terminated by a period. --------------- To go along with the above, we should add the following to section 12.1.3 within our guidelines for defining packages: For packages implementing detection of CAS signalling (for example, DTMF detection), this section should also contain a mapping between events of the package and the digit map symbols "0" through "9" and, as necessary, "A" through "K". As indicated in section 7.1.14, digits "0" through "9" MUST be mapped to the corresponding digit events within the signalling system concerned. Letters should be allocated in logical fashion, facilitating the use of range notation for alternative events. This section MUST also define an event to be used to notify the MGC when a digit map string has been matched by events of this package. We also need to add the mapping and digit map match event to the DTMF and R2 packages. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Tuesday, January 11, 2000 8:10 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Digit Map Symbols > > It has troubled me that the syntax for digit maps contains symbols which > are > signalling system specific (particularly the MF symbols). I propose the > following alternative: > > 1. The digit map symbol set consists of the digits "0" through "9" and "A" > through "F" (besides the extra stuff like "x", "L", and "S"). > > 2. A package may define a mapping between events of that package and > symbols > of the digit map symbol set. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 11:21:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18498 for ; Wed, 12 Jan 2000 11:20:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A2EDF80@standards.nortelnetworks.com>; Wed, 12 Jan 2000 11:09:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120460 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 11:08:45 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.644BFF90@standards.nortelnetworks.com>; Wed, 12 Jan 2000 11:08:44 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 10:17:56 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 12 Jan 2000 11:17:39 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 10:17:38 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 12 Jan 2000 10:17:26 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Meeting In Adelaide To: MEGACO@STANDARDS.NORTELNETWORKS.COM Should I schedule a meeting of the WG for Adelaide? Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 14:38:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22947 for ; Wed, 12 Jan 2000 14:38:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0682FDC0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 14:26:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120819 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 14:25:53 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE44EFC0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 14:25:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 13:35:52 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 12 Jan 2000 14:35:28 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 13:35:27 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 12 Jan 2000 13:35:19 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: Application for port-number To: MEGACO@STANDARDS.NORTELNETWORKS.COM I've requested a single port number pair (TCP/UDP) for Megaco/H.248. See below. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Wednesday, January 12, 2000 2:29 PM > To: iana@iana.org; Taylor, Tom-PT [CAR:B904:EXCH] > Subject: Application for port-number > > Name : > Tom Taylor > > E-mail : > taylor@NortelNetworks.com > > Protocol Number : > TCP & UDP > > Message Formats : > For full documentation see ITU-T Recommendation H.248 (RFC number > forthcoming). > Message overhead consists of ptional authentication header, protocol name > (MEGACO) and version, and an originator identifier. The body of the > message > consists of one or more independent transaction requests or responses, or > an > error response to an indecipherable message. The protocol comes in > text-encoded > and ASN.1 BER binary-encoded versions. > > Message Types : > A message is just a transport container for transactions and their > responses. > Except for the authentication header, the message overhead should be the > same > for every message from the same originator. > > Message opcodes : > Not applicable at the message level. Transactions contain actions > which contain commands. The possible commands are Add, Modify, Move, > Subtract, > AuditCapability, AuditValue, and ServiceChange. > > Message Sequences : > Not applicable at the message level. TransactionRequests within messages > will be followed by TransactionReply or TransactionPending responses. The > same message may contain multiple transactions (requests and/or > responses), which are independent of each other. > > Protocol functions : > The protocol operates between a Media Gateway Controller and a Media > Gateway > to control the connection and manipulation of media streams through the > latter, > typically in the provision of IP telephony or multimedia conferencing > service. > > Broadcast or Multicast used ? > no > > How and what for Broadcast or Multicast is used (if used): > > > Range for port number : > user port > > Description : > This will be a rendezvous port through which the Media Gateway registers > its > presence with a Media Gateway Controller. Assignment of a well-known port > > simplifies administration of the Media Gateway and Controller. > > The Media Gateway has the option to use either UDP or TCP. The Media > Gateway > Controller has the option to assign an alternative address and/or port for > > establishment of the association, but must respect the initial choice of > protocol. > > Name of the port : > Megaco/H.248 > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 16:35:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25185 for ; Wed, 12 Jan 2000 16:35:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71244070@standards.nortelnetworks.com>; Wed, 12 Jan 2000 16:24:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 120927 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 16:22:44 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DBAE56D0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 16:12:44 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 12 Jan 2000 15:22:59 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 12 Jan 2000 16:22:52 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 12 Jan 2000 16:22:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5D43.2D193262" Message-ID: <29400B68197CD31188830000F8CD15D39B4ECD@zcard00q.ca.nortel.com> Date: Wed, 12 Jan 2000 16:22:44 -0500 Reply-To: Arvind Saxena Sender: "Media Gateway Control (megaco)" From: Arvind Saxena To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5D43.2D193262 Content-Type: text/plain; charset="iso-8859-1" Can any body explain the difference between MGCP and Megaco Standard ? Thanks. -------------------------------------------------- Arvind K. Saxena Nortel Networks 3500 Carling Avenue Mail Stop 043/63/F6 Nepean, Ontario K2H 8E9 (Canada) ---------------------------------------------------- Tel: 613-768-2203 (ESN: 398) Fax: 613 768 -4069 E-Mail: saxenaa@nortelnetworks.com ------_=_NextPart_001_01BF5D43.2D193262 Content-Type: text/html; charset="iso-8859-1"

        Can any body explain the difference between MGCP and Megaco Standard ?
        Thanks.
        --------------------------------------------------
        Arvind K. Saxena
        Nortel Networks
        3500 Carling Avenue
        Mail Stop 043/63/F6
        Nepean, Ontario K2H 8E9 (Canada)
        ----------------------------------------------------
        Tel: 613-768-2203 (ESN: 398)
        Fax: 613 768 -4069
        E-Mail: saxenaa@nortelnetworks.com

        ------_=_NextPart_001_01BF5D43.2D193262-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 18:32:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26855 for ; Wed, 12 Jan 2000 18:32:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BABCF050@standards.nortelnetworks.com>; Wed, 12 Jan 2000 18:20:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121094 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 18:19:34 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93558180@standards.nortelnetworks.com>; Wed, 12 Jan 2000 18:19:33 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id PAA17154; Wed, 12 Jan 2000 15:23:28 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 12 Jan 2000 23:29:30 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA15327; Wed, 12 Jan 2000 15:29:29 -0800 (PST) Received: from ascend.com by ascend.com X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000112152832.00abe490@porky> Date: Wed, 12 Jan 2000 15:29:59 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: Meeting In Adelaide X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 10:17 AM 1/12/00 -0600, Tom-PT Taylor wrote: >Should I schedule a meeting of the WG for Adelaide? Gee, isn't there a lot of work to do on packages, the MIB, etc.? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 18:47:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26928 for ; Wed, 12 Jan 2000 18:47:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6243FE0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 18:35:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121122 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 18:35:43 -0500 Received: from marlborough.cnchost.com (207.155.248.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F7AED80@standards.nortelnetworks.com>; Wed, 12 Jan 2000 18:25:43 -0500 Received: from ipcell023 ([208.176.101.190]) by marlborough.cnchost.com id SAA17292; Wed, 12 Jan 2000 18:29:03 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Errors-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01BF5D22.B47B3D70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Wed, 12 Jan 2000 17:32:49 -0600 Reply-To: Mehul Shah Sender: "Media Gateway Control (megaco)" From: Mehul Shah X-To: Arvind Saxena To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BF5D22.B47B3D70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi, (1) MGCP is based on the model, which involves Endpoint Handling and Connection Handling whereas Megaco standard is based on the model, which has Terminations and Contexts. Megaco standard even considers RTP/RTCP sessions as Terminations which is not the case in MGCP protocol. (2) Megaco has defined new messages (Message names are different) on top of MGCP messages. (3) Adding new features with Megaco protocol is much more simpler than with MGCP. We have to manuplate only Terminations. (4) Megaco has seperate document for packages compared to MGCP. Also Megaco has defined more new packages. (5) MGCP protocol uses UDP whereas Megaco is open for both UDP as well as TCP. (6) Megaco seems to be binary protocol whereas MGCP is text based protocol (I am not sure about this). (7) In short, Megaco standard is removing the weak points of MGCP protocol. Please let me know if you require any other information. Thanks and Regards, Mehul K. Shah, IPCell Technologies Inc., Richardson Dallas. -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Arvind Saxena Sent: Wednesday, January 12, 2000 3:23 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Can any body explain the difference between MGCP and Megaco Standard ? Thanks. -------------------------------------------------- Arvind K. Saxena Nortel Networks 3500 Carling Avenue Mail Stop 043/63/F6 Nepean, Ontario K2H 8E9 (Canada) ---------------------------------------------------- Tel: 613-768-2203 (ESN: 398) Fax: 613 768 -4069 E-Mail: saxenaa@nortelnetworks.com ------=_NextPart_000_0006_01BF5D22.B47B3D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
        Hi,
         
        (1)=20 MGCP is based on the model, which involves Endpoint Handling and = Connection=20 Handling whereas
             Megaco standard is = based on=20 the model, which has Terminations and Contexts. Megaco=20 standard
             even considers = RTP/RTCP=20 sessions as Terminations which is not the case in MGCP=20 protocol.
         
        (2)=20 Megaco has defined new messages (Message names are different) on top of = MGCP=20 messages.
         
        (3)=20 Adding new features with Megaco protocol is much more simpler than with = MGCP. We=20 have to
             manuplate only=20 Terminations.
         
        (4)=20 Megaco has seperate document for packages compared to MGCP. Also Megaco = has=20 defined more
           =20 new packages.
         
        (5)=20 MGCP protocol uses UDP whereas Megaco is open for both UDP as well as=20 TCP.
         
        (6)=20 Megaco seems to be binary protocol whereas MGCP is text based protocol = (I am not=20 sure about this).
         
        (7) In=20 short, Megaco standard is removing the weak points of MGCP=20 protocol.
         
         
        Please=20 let me know if you require any other information.
         
        Thanks=20 and Regards,
        Mehul=20 K. Shah,
        IPCell=20 Technologies Inc.,
        Richardson Dallas.
        -----Original Message-----
        From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of=20 Arvind Saxena
        Sent: Wednesday, January 12, 2000 3:23=20 PM
        To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
        Subject:=20

        Can any body explain the difference = between MGCP=20 and Megaco Standard ?
        Thanks.=20
        -------------------------------------------------- =
        Arvind K. Saxena =
        Nortel Networks =
        3500 Carling Avenue =
        Mail Stop 043/63/F6 =
        Nepean, Ontario K2H 8E9 = (Canada)=20
        ---------------------------------------------------- =
        Tel: 613-768-2203 = (ESN:=20 398)
        Fax: 613 768=20 -4069
        E-Mail:=20 saxenaa@nortelnetworks.com

        ------=_NextPart_000_0006_01BF5D22.B47B3D70-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 12 19:47:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27350 for ; Wed, 12 Jan 2000 19:47:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4452C1A0@standards.nortelnetworks.com>; Wed, 12 Jan 2000 19:36:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 121282 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 12 Jan 2000 19:34:08 -0500 Received: from sj-mailhub-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE7E2B60@standards.nortelnetworks.com>; Wed, 12 Jan 2000 19:34:08 -0500 Received: from airborne.cisco.com (airborne.cisco.com [171.71.154.32]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id QAA08701; Wed, 12 Jan 2000 16:47:26 -0800 (PST) Received: from cisco.com (dhcp-71-147-155.cisco.com [171.71.147.155]) by Mirapoint Server airborne.cisco.com with ESMTP id ACP04638 Wed, 12 Jan 2000 16:44:46 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387D2059.F3F7609E@cisco.com> Date: Wed, 12 Jan 2000 16:46:17 -0800 Reply-To: Cary FitzGerald Sender: "Media Gateway Control (megaco)" From: Cary FitzGerald Organization: Cisco Systems X-To: Mehul Shah To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think that it would be fair to say that there has been considerable debate as to whether most of the points below represent strengths or weaknesses. Rather than risk re-igniting the debate, I would refer you to the extensive mail archive for the megaco WG. In the end, the WG never reached consensus on many of the most contentious questions. The WG chair took an entirely reasonable step to make certain decisions, at one point resorting to resolving an un-resolvable technical debate by flipping a coin (which was probably the most reasonable thing to do at the time). No minds were changed as a result of the coin flip, but a specific point was called resolved and the debate moved on (well, sort of). The end result of all these decisions is the megaco protocol. Development for MGCP stopped on the megaco mailing list once the WG made the decision to proceed with megaco/H.248. There has been considerable work on MGCP in CableLabs (www.cablelabs.org). Cary. Mehul Shah wrote: > Hi,(1) MGCP is based on the model, which involves Endpoint > Handling and Connection Handling whereas Megaco > standard is based on the model, which has Terminations and > Contexts. Megaco standard even considers RTP/RTCP > sessions as Terminations which is not the case in MGCP > protocol.(2) Megaco has defined new messages (Message > names are different) on top of MGCP messages.(3) Adding > new features with Megaco protocol is much more simpler > than with MGCP. We have to manuplate only > Terminations.(4) Megaco has seperate document for packages > compared to MGCP. Also Megaco has defined more new > packages.(5) MGCP protocol uses UDP whereas Megaco is open > for both UDP as well as TCP.(6) Megaco seems to be binary > protocol whereas MGCP is text based protocol (I am not > sure about this).(7) In short, Megaco standard is removing > the weak points of MGCP protocol.Please let me know if you > require any other information.Thanks and Regards,Mehul K. > Shah,IPCell Technologies Inc.,Richardson Dallas. > > -----Original Message----- > From: Media Gateway Control (megaco) > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On > Behalf Of Arvind Saxena > Sent: Wednesday, January 12, 2000 3:23 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: > Can any body explain the difference between MGCP > and Megaco Standard ? > Thanks. > > ------------------------------------------------- > > Arvind K. Saxena > Nortel Networks > 3500 Carling Avenue > Mail Stop 043/63/F6 > Nepean, Ontario K2H 8E9 (Canada) > > --------------------------------------------------- > > Tel: 613-768-2203 (ESN: 398) > Fax: 613 768 -4069 > E-Mail: saxenaa@nortelnetworks.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 09:52:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19373 for ; Thu, 13 Jan 2000 09:52:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4E59E180@standards.nortelnetworks.com>; Thu, 13 Jan 2000 9:41:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 122774 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 09:39:04 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0770A6F0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 9:39:04 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 13 Jan 2000 08:47:53 -0600 Received: from zcard00n.ca.nortel.com by zmers013; Thu, 13 Jan 2000 09:47:46 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C3GKD317; Thu, 13 Jan 2000 09:47:46 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MSN2G; Thu, 13 Jan 2000 09:47:45 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <387D2059.F3F7609E@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387DE5F1.E5A0EC98@americasm01.nt.com> Date: Thu, 13 Jan 2000 09:49:21 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks X-To: Cary FitzGerald To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nancy Greene has put a document on MEGACO vs MGCP back in Sept 99. Interested parties could find it in, Abdallah Rayhan Cary FitzGerald wrote: > I think that it would be fair to say that there has been > considerable debate as to whether most of the points below > represent strengths or weaknesses. > > Rather than risk re-igniting the debate, I would refer you > to the extensive mail archive for the megaco WG. In the > end, the WG never reached consensus on many of the most > contentious questions. The WG chair took an entirely > reasonable step to make certain decisions, at one point > resorting to resolving an un-resolvable technical debate by > flipping a coin (which was probably the most reasonable > thing to do at the time). No minds were changed as a result > of the coin flip, but a specific point was called resolved > and the debate moved on (well, sort of). The end result of > all these decisions is the megaco protocol. > > Development for MGCP stopped on the megaco mailing list once > the WG made the decision to proceed with megaco/H.248. > There has been considerable work on MGCP in CableLabs > (www.cablelabs.org). > > Cary. > > Mehul Shah wrote: > > > Hi,(1) MGCP is based on the model, which involves Endpoint > > Handling and Connection Handling whereas Megaco > > standard is based on the model, which has Terminations and > > Contexts. Megaco standard even considers RTP/RTCP > > sessions as Terminations which is not the case in MGCP > > protocol.(2) Megaco has defined new messages (Message > > names are different) on top of MGCP messages.(3) Adding > > new features with Megaco protocol is much more simpler > > than with MGCP. We have to manuplate only > > Terminations.(4) Megaco has seperate document for packages > > compared to MGCP. Also Megaco has defined more new > > packages.(5) MGCP protocol uses UDP whereas Megaco is open > > for both UDP as well as TCP.(6) Megaco seems to be binary > > protocol whereas MGCP is text based protocol (I am not > > sure about this).(7) In short, Megaco standard is removing > > the weak points of MGCP protocol.Please let me know if you > > require any other information.Thanks and Regards,Mehul K. > > Shah,IPCell Technologies Inc.,Richardson Dallas. > > > > -----Original Message----- > > From: Media Gateway Control (megaco) > > [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On > > Behalf Of Arvind Saxena > > Sent: Wednesday, January 12, 2000 3:23 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: > > Can any body explain the difference between MGCP > > and Megaco Standard ? > > Thanks. > > > > ------------------------------------------------- > > > > Arvind K. Saxena > > Nortel Networks > > 3500 Carling Avenue > > Mail Stop 043/63/F6 > > Nepean, Ontario K2H 8E9 (Canada) > > > > --------------------------------------------------- > > > > Tel: 613-768-2203 (ESN: 398) > > Fax: 613 768 -4069 > > E-Mail: saxenaa@nortelnetworks.com > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 14:51:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24442 for ; Thu, 13 Jan 2000 14:51:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.17AE1DC0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 14:40:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123169 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 14:38:58 -0500 Received: from lethe.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87126BF0@standards.nortelnetworks.com>; Thu, 13 Jan 2000 14:28:58 -0500 Received: from richen1-nt (dhcp-71-147-241.cisco.com [171.71.147.241]) by lethe.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id LAA19079 for ; Thu, 13 Jan 2000 11:39:40 -0800 (PST) X-Sender: richen@lethe.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000113111318.00c39be0@lethe.cisco.com> Date: Thu, 13 Jan 2000 11:39:06 -0800 Reply-To: Rick Chen Sender: "Media Gateway Control (megaco)" From: Rick Chen Subject: Question in Appendix A -example call flows in ITU-T H.248 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, In Appendix A - Example Call Flows (ITU-T H.248 dated 12/22/99), step 16 is to give IPAddr and UDPport to MG1. There is a mismatch with the protocol description which is : from MGC to MG1: MEGACO/1.0 [123.123.123.4]:55555 Transaction = 10005 { Context = 2000 { Modify = A4444 { Signals {g/PlayTone{tone=ringback}} } } } Regards, Rick From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 13 23:49:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00347 for ; Thu, 13 Jan 2000 23:49:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32B6C860@standards.nortelnetworks.com>; Thu, 13 Jan 2000 23:37:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123340 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 13 Jan 2000 23:37:41 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F0B4C90@standards.nortelnetworks.com>; Thu, 13 Jan 2000 23:37:41 -0500 Received: from zrchh190 by smtprich.nortel.com; Thu, 13 Jan 2000 22:49:02 -0600 Received: from zrchb213.us.nortel.com by zrchh190; Thu, 13 Jan 2000 22:55:57 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 13 Jan 2000 22:47:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5E4A.6493F152" X-Orig: Message-ID: Date: Thu, 13 Jan 2000 22:46:57 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: Question in Appendix A -example call flows in ITU-T H.248 X-To: Rick Chen To: MEGACO@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01BF5E4A.6493F152 Content-type: text/plain; charset="us-ascii" Rick, good to see someone is reading the examples! Yes this is an error - draft-05 (v13) of the protocol will be out this week, and it has an updated Appendix A. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Rick Chen[SMTP:richen@CISCO.COM] > Sent: Thursday, January 13, 2000 2:39 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Question in Appendix A -example call flows in ITU-T H.248 > > Hi, > > In Appendix A - Example Call Flows (ITU-T H.248 dated 12/22/99), step 16 > is to give IPAddr and UDPport to MG1. There is a mismatch with the > protocol description which is : > > from MGC to MG1: > MEGACO/1.0 [123.123.123.4]:55555 > Transaction = 10005 { > Context = 2000 { > Modify = A4444 { > Signals {g/PlayTone{tone=ringback}} > } > } > } > > > > Regards, > Rick > ------_=_NextPart_001_01BF5E4A.6493F152 Content-type: text/html Content-Transfer-Encoding: quoted-printable RE: Question in Appendix A -example call flows in ITU-T = H.248

        Rick, good to see = someone is reading the examples! Yes this is an error - draft-05 (v13) = of the protocol will be out this week, and it has an updated Appendix = A.

        Nancy
        -----------------------------------------------------------------= ---------
        Nancy M. Greene
        Internet & Service = Provider Networks, Nortel Networks
        T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

          ----------
          From:   = Rick = Chen[SMTP:richen@CISCO.COM]
          Sent:   = Thursday, January 13, 2000 2:39 = PM
          To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject: =        Question in Appendix A -example call flows in ITU-T H.248

          Hi,

          In  Appendix A - Example Call = Flows (ITU-T H.248 dated 12/22/99), step 16 is to give IPAddr and = UDPport to MG1. There is a mismatch with the protocol description which = is :

          from MGC to MG1:
          MEGACO/1.0 = [123.123.123.4]:55555
          Transaction =3D 10005 {
            Context =3D 2000 {
                Modify = =3D A4444 {
                   &nb= sp; Signals {g/PlayTone{tone=3Dringback}}
                = }
             }
           }



          Regards,
          Rick

        ------_=_NextPart_001_01BF5E4A.6493F152-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 01:16:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01643 for ; Fri, 14 Jan 2000 01:16:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.655F91F0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 1:05:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123417 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 01:04:10 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3FA9F1D0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 1:04:03 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA02262 for ; Fri, 14 Jan 2000 12:13:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256866.0021B9AD ; Fri, 14 Jan 2000 11:38:22 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256866.0021B8F4.00@sandesh.hss.hns.com> Date: Fri, 14 Jan 2000 11:39:19 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: "unspecified" Context Identifier for Audit Command To: MEGACO@STANDARDS.NORTELNETWORKS.COM HI all, the Audit Value command description refers about "unspecified" context identifier. The intrepretation of "unspecified" is not described any where. Since according to the context identifier definition it can only take ALL, CHOOSE, NULL and fully specified values. The "unspecified" context identifier is not supported by the grammar too. I think the "unspecified" means "Dont care". Is this the intention. regards -Madhubabu Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 09:19:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17236 for ; Fri, 14 Jan 2000 09:19:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.827C9740@standards.nortelnetworks.com>; Fri, 14 Jan 2000 9:05:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123573 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 09:03:48 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DEF68500@standards.nortelnetworks.com>; Fri, 14 Jan 2000 8:53:47 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA04689; Fri, 14 Jan 2000 09:04:27 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA15928; Fri, 14 Jan 2000 09:04:30 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 09:01:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087B6@whq-msgusr-02.fore.com> Date: Fri, 14 Jan 2000 09:04:28 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: "unspecified" Context Identifier for Audit Command X-To: "bmbabu@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, you are correct. Looking at the table, there are two instances of "unspecified", with root and with wildcard. I believe we can get rid of the line with unspecified/Root as this will return the same results as Null/Root. I think we can change unspecified to "ALL" with wildcard to audit matching terminations and the contexts to which they are associated. That should fix the problem. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@hss.hns.com] > Sent: Friday, January 14, 2000 1:09 AM > To: MEGACO@standards.nortelnetworks.com > Subject: "unspecified" Context Identifier for Audit Command > > > HI all, > the Audit Value command description refers about > "unspecified" context > identifier. The intrepretation of "unspecified" > is not described any where. Since according to the context > identifier definition > it can only take ALL, CHOOSE, NULL and fully > specified values. The "unspecified" context identifier is not > supported by the > grammar too. I think the "unspecified" means > "Dont care". Is this the intention. > regards > -Madhubabu > Hughes Software Systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 09:47:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17882 for ; Fri, 14 Jan 2000 09:47:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B9C23B20@standards.nortelnetworks.com>; Fri, 14 Jan 2000 9:35:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123636 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 09:34:08 -0500 Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1899C7F0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 9:24:02 -0500 Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id IAA05681 for ; Fri, 14 Jan 2000 08:34:25 -0600 (CST) Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id xma005543; Fri, 14 Jan 00 08:33:41 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id IAA10376 for ; Fri, 14 Jan 2000 08:33:40 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAB245D for ; Fri, 14 Jan 2000 08:33:36 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id IAA01824 for ; Fri, 14 Jan 2000 08:33:16 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA11782 for ; Fri, 14 Jan 2000 08:33:15 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------C3BC50C894EB25CE7DB3EE27" Message-ID: <387F33AB.114F9F27@usa.alcatel.com> Date: Fri, 14 Jan 2000 08:33:15 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Unspecified mandatory parameters To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------C3BC50C894EB25CE7DB3EE27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi In section 7.1.1 "Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the command responder ..." Can someone give me an example of an unspecified mandatory parameter in a descriptor? Does this result in a syntax error? How do I tell if a parameter is mandatory - based ABNF? Thanks Chuong -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------C3BC50C894EB25CE7DB3EE27 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi

        In section 7.1.1
        "Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor)
        result in the command responder ..."

        Can someone give me an example of an unspecified mandatory parameter in a descriptor?

        Does this result in a syntax error?
        How do I tell if a parameter is mandatory - based ABNF?

        Thanks
        Chuong 

        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
          --------------C3BC50C894EB25CE7DB3EE27-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 10:24:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18286 for ; Fri, 14 Jan 2000 10:24:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81DEE190@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:09:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123743 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 10:09:43 -0500 Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A266900@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:09:43 -0500 Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18671 for ; Fri, 14 Jan 2000 08:20:19 -0700 (MST) X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387F3EC0.55C1B1A8@aztek-eng.com> Date: Fri, 14 Jan 2000 08:20:32 -0700 Reply-To: Jo Friedman Sender: "Media Gateway Control (megaco)" From: Jo Friedman Organization: Aztek Engineering Subject: ABNF discrepancies? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I suspect that two of the Megaco ABNF rules aren't correct. 1. The rule for eventOther can lead to an encoding with two equal signs (or =>, =<, etc) because eventOther has EQUAL in its definition and parmValue also has an EQUAL in its definition. It appears the EQUAL should be dropped from the definition of eventOther (similar to how propertyParm is defined). The rule should probably be: eventOther = eventParameterName parmValue 2. The rules for localDescriptor and remoteDescriptor don't include the string "= SDP", nor surrounding { } as shown in the examples in Appendix A. It seems like the usage in the examples makes sense for parsing the SDP descriptors.The rule should probably be: localDescriptor = LocalToken EQUAL SdpToken LBRKT octetstring RBRKT Did these get changed in the upcoming draft? Jo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 10:32:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18426 for ; Fri, 14 Jan 2000 10:32:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1D15EA0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:20:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123812 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 10:19:58 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E8DE1C20@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:19:58 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 09:29:34 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 10:29:23 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 10:29:23 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 10:29:21 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Draft Megaco/H.248 v13 X-cc: Brian Rosen , Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM Brian and Nancy are about to put out a draft version of the protocol document on the Megaco working website -- Nancy can announce the file name. This document is in an inconsistent state. We are hoping to clean up by tonight, but I am aware that people have to have the latest available information in order to prepare contributions for the US ITU process meeting on Tuesday. Please keep an eye on the list today and feel free to step in yourself, to bring this work to a close. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 10:36:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18462 for ; Fri, 14 Jan 2000 10:36:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.82277160@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:24:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123840 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 10:22:42 -0500 Received: from thumper.research.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A9C1520@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:22:42 -0500 Received: from seascape.research.telcordia.com (pptpdhcp25 [192.4.9.250]) by thumper.research.telcordia.com (8.9.3/8.9.3) with SMTP id KAA02436; Fri, 14 Jan 2000 10:26:05 -0500 (EST) X-Sender: huitema@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000114101946.009fc590@mailee.research.telcordia.com> Date: Fri, 14 Jan 2000 10:21:47 -0500 Reply-To: Christian Huitema Sender: "Media Gateway Control (megaco)" From: Christian Huitema Subject: Re: FW: Application for port-number X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote: >I've requested a single port number pair (TCP/UDP) for Megaco/H.248. See >below. In fact, it would make sense to require separate port numbers for the MG and for the MGC, to facilitate the writing of ACL in firewalls or similar devices. Also, it might make sense to use separate port numbers for the text and ASN.1 encodings -- that would limit confusion. -- Christian Huitema From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 10:48:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18636 for ; Fri, 14 Jan 2000 10:47:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.327E2760@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:36:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 123905 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 10:34:46 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F9C8CA10@standards.nortelnetworks.com>; Fri, 14 Jan 2000 10:34:45 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 09:44:53 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 10:44:46 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 10:44:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5EA6.474A4036" Message-ID: Date: Fri, 14 Jan 2000 10:44:42 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: FW: Application for port-number X-To: Christian Huitema To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5EA6.474A4036 Content-Type: text/plain On your first point, the only purpose of these ports is to give the MG somewhere to go to initiate the association. If it's TCP, the MG port is fixed at that point. If it's UDP, the MG can signal which port it wants to receive at. I thought about your second point, but figured the outcome would be the same, regardless: if the MGC doesn't understand a particular encoding, it will have no choice but to ignore the association attempt, since it won't even be able to recognize the protocol. Perhaps that's a hole we should fix so the MG can at least be told that the MGC doesn't understand it. > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Friday, January 14, 2000 10:22 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com > Subject: Re: FW: Application for port-number > > At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote: > >I've requested a single port number pair (TCP/UDP) for Megaco/H.248. See > >below. > > In fact, it would make sense to require separate port numbers for the MG > and for the MGC, to facilitate the writing of ACL in firewalls or similar > devices. Also, it might make sense to use separate port numbers for the > text and ASN.1 encodings -- that would limit confusion. > -- Christian Huitema ------_=_NextPart_001_01BF5EA6.474A4036 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: Application for port-number

        On your first point, = the only purpose of these ports is to give the MG somewhere to go to = initiate the association.  If it's TCP, the MG port is fixed at = that point.  If it's UDP, the MG can signal which port it wants to = receive at.

        I thought about your = second point, but figured the outcome would be the same, regardless: if = the MGC doesn't understand a particular encoding, it will have no = choice but to ignore the association attempt, since it won't even be = able to recognize the protocol.  Perhaps that's a hole we should = fix so the MG can at least be told that the MGC doesn't understand = it.

          -----Original Message-----
          From:   Christian Huitema = [SMTP:huitema@research.telcordia.com]
          Sent:   Friday, January 14, 2000 10:22 AM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]; = MEGACO@standards.nortelnetworks.com
          Subject:       = Re: FW: Application for = port-number

          At 01:35 PM 1/12/00 -0600, Tom-PT = Taylor wrote:
          >I've requested a single port = number pair (TCP/UDP) for Megaco/H.248.  See
          >below.

          In fact, it would make sense to = require separate port numbers for the MG
          and for the MGC, to facilitate the = writing of ACL in firewalls or similar
          devices. Also, it might make sense to = use separate port numbers for the
          text and ASN.1 encodings -- that = would limit confusion.
          -- Christian Huitema

        ------_=_NextPart_001_01BF5EA6.474A4036-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 11:43:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19697 for ; Fri, 14 Jan 2000 11:43:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E73F7BC0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:31:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124003 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 11:30:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1EB98F0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:30:01 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 10:40:00 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Fri, 14 Jan 2000 11:39:54 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0BD0WY; Fri, 14 Jan 2000 11:39:18 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MSSCN; Fri, 14 Jan 2000 11:39:19 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <387F3EC0.55C1B1A8@aztek-eng.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <387F5197.78FAE68D@americasm01.nt.com> Date: Fri, 14 Jan 2000 11:40:55 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: ABNF discrepancies? X-To: Jo Friedman To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Jo, Notice has been taken. The V13 will have fixes for all of these as well all the ABNF remarks brought up on this list. Abdallah Rayhan Jo Friedman wrote: > I suspect that two of the Megaco ABNF rules aren't correct. > > 1. The rule for eventOther can lead to an encoding with two equal > signs (or =>, =<, etc) because eventOther has EQUAL in its > definition and parmValue also has an EQUAL in its definition. It > appears the EQUAL should be dropped from the definition of > eventOther (similar to how propertyParm is defined). The rule > should probably be: > eventOther = eventParameterName parmValue > > 2. The rules for localDescriptor and remoteDescriptor don't > include the string "= SDP", nor surrounding { } as shown in the > examples in Appendix A. It seems like the usage in the examples > makes sense for parsing the SDP descriptors.The rule should > probably be: > localDescriptor = LocalToken EQUAL SdpToken LBRKT octetstring > RBRKT > > Did these get changed in the upcoming draft? > > Jo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 11:53:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19870 for ; Fri, 14 Jan 2000 11:53:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4E8646A0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:41:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124036 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 11:40:03 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.18ACE020@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:40:03 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 10:50:02 -0600 Received: from zcard00n.ca.nortel.com by zmers013; Fri, 14 Jan 2000 11:49:43 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C3GKGHGZ; Fri, 14 Jan 2000 11:49:43 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MSS1F; Fri, 14 Jan 2000 11:49:43 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------EDD318DBB69D188AB2BDBFD8" Message-ID: <387F5407.1C1E1A7D@americasm01.nt.com> Date: Fri, 14 Jan 2000 11:51:19 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: FW: Application for port-number X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------EDD318DBB69D188AB2BDBFD8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Either a different port or a BinaryToken in the ASN.1 to differentiate binary and text. Or the other way around in the ABNF, e.g., you look for a particular token at the beginning the message. If present then binary encoding is assumed, otherwise text encoding. Abdallah Rayhan "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > On your first point, the only purpose of these ports is to give the MG > somewhere to go to initiate the association. If it's TCP, the MG port > is fixed at that point. If it's UDP, the MG can signal which port it > wants to receive at. > > I thought about your second point, but figured the outcome would be > the same, regardless: if the MGC doesn't understand a particular > encoding, it will have no choice but to ignore the association > attempt, since it won't even be able to recognize the protocol. > Perhaps that's a hole we should fix so the MG can at least be told > that the MGC doesn't understand it. > > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Friday, January 14, 2000 10:22 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > Subject: Re: FW: Application for port-number > > At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote: > >I've requested a single port number pair (TCP/UDP) for > Megaco/H.248. See > >below. > > In fact, it would make sense to require separate port numbers for > the MG > and for the MGC, to facilitate the writing of ACL in firewalls or > similar > devices. Also, it might make sense to use separate port numbers > for the > text and ASN.1 encodings -- that would limit confusion. > -- Christian Huitema > --------------EDD318DBB69D188AB2BDBFD8 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Either a different port or a BinaryToken in the ASN.1 to differentiate
        binary and text. Or the other way around in the ABNF, e.g., you look
        for a particular token  at the beginning the message. If present then
        binary encoding is assumed, otherwise text encoding.

        Abdallah Rayhan
         

        "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote:

         

        On your first point, the only purpose of these ports is to give the MG somewhere to go to initiate the association.  If it's TCP, the MG port is fixed at that point.  If it's UDP, the MG can signal which port it wants to receive at.

        I thought about your second point, but figured the outcome would be the same, regardless: if the MGC doesn't understand a particular encoding, it will have no choice but to ignore the association attempt, since it won't even be able to recognize the protocol.  Perhaps that's a hole we should fix so the MG can at least be told that the MGC doesn't understand it.

          -----Original Message-----
          From:   Christian Huitema [SMTP:huitema@research.telcordia.com]
          Sent:   Friday, January 14, 2000 10:22 AM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
          Subject:        Re: FW: Application for port-number

          At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote:
          >I've requested a single port number pair (TCP/UDP) for Megaco/H.248.  See
          >below.

          In fact, it would make sense to require separate port numbers for the MG
          and for the MGC, to facilitate the writing of ACL in firewalls or similar
          devices. Also, it might make sense to use separate port numbers for the
          text and ASN.1 encodings -- that would limit confusion.
          -- Christian Huitema

        --------------EDD318DBB69D188AB2BDBFD8-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 12:04:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20137 for ; Fri, 14 Jan 2000 12:04:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E465E70@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:49:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124067 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 11:49:03 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A5A9390@standards.nortelnetworks.com>; Fri, 14 Jan 2000 11:49:02 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 10:58:59 -0600 Received: from zrchb213.us.nortel.com by zmers013; Fri, 14 Jan 2000 11:58:50 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 10:58:48 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 10:58:49 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: FW: Application for port-number To: MEGACO@STANDARDS.NORTELNETWORKS.COM Further to this point, I would propose the following modification to section 7.2.9. Following the sentence "MGCs should support both encoding formats.": add the sentence: "If an MGC does not support a given encoding method, it MUST at least be able to recognize a ServiceChange command within that encoding and be able to return an error reply indicating error 501 - Not implemented." > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Friday, January 14, 2000 10:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Application for port-number > > On your first point, the only purpose of these ports is to give the MG > somewhere to go to initiate the association. If it's TCP, the MG port is > fixed at that point. If it's UDP, the MG can signal which port it wants > to receive at. > > I thought about your second point, but figured the outcome would be the > same, regardless: if the MGC doesn't understand a particular encoding, it > will have no choice but to ignore the association attempt, since it won't > even be able to recognize the protocol. Perhaps that's a hole we should > fix so the MG can at least be told that the MGC doesn't understand it. > > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Friday, January 14, 2000 10:22 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > Subject: Re: FW: Application for port-number > > At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote: > >I've requested a single port number pair (TCP/UDP) for Megaco/H.248. See > > >below. > > In fact, it would make sense to require separate port numbers for > the MG > and for the MGC, to facilitate the writing of ACL in firewalls or similar > devices. Also, it might make sense to use separate port numbers for the > text and ASN.1 encodings -- that would limit confusion. > -- Christian Huitema > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 12:18:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20338 for ; Fri, 14 Jan 2000 12:18:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1C35AA0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 12:06:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124134 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 12:05:18 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F8E1CF0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 12:05:18 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 11:15:08 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 12:15:04 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 12:15:05 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 12:15:03 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: FW: Application for port-number X-To: Abdallah Rayhan To: MEGACO@STANDARDS.NORTELNETWORKS.COM The key differentiator is the presence or absence of the word MEGACO in text encoding. ASN.1 has its own well-defined structure, of course, so an ASN.1-savvy implementation will be able to pick that out quickly enough. > -----Original Message----- > From: Rayhan, Abdallah [CAR:5N00:EXCH] [SMTP:arayhan@americasm01.nt.com] > Sent: Friday, January 14, 2000 11:51 AM > To: Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Application for port-number > > Either a different port or a BinaryToken in the ASN.1 to differentiate > binary and text. Or the other way around in the ABNF, e.g., you look > for a particular token at the beginning the message. If present then > binary encoding is assumed, otherwise text encoding. > > Abdallah Rayhan > > > "Taylor, Tom-PT (P.T.) [EXCHANGE:CAR:B904]" wrote: > > > > On your first point, the only purpose of these ports is to give the > MG somewhere to go to initiate the association. If it's TCP, the MG port > is fixed at that point. If it's UDP, the MG can signal which port it > wants to receive at. > > I thought about your second point, but figured the outcome would be > the same, regardless: if the MGC doesn't understand a particular encoding, > it will have no choice but to ignore the association attempt, since it > won't even be able to recognize the protocol. Perhaps that's a hole we > should fix so the MG can at least be told that the MGC doesn't understand > it. > > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Friday, January 14, 2000 10:22 AM > To: Taylor, Tom-PT [CAR:B904:EXCH]; > MEGACO@standards.nortelnetworks.com > Subject: Re: FW: Application for port-number > > At 01:35 PM 1/12/00 -0600, Tom-PT Taylor wrote: > >I've requested a single port number pair (TCP/UDP) for > Megaco/H.248. See > >below. > > In fact, it would make sense to require separate port > numbers for the MG > and for the MGC, to facilitate the writing of ACL in firewalls or > similar > devices. Also, it might make sense to use separate port numbers for > the > text and ASN.1 encodings -- that would limit confusion. > -- Christian Huitema > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 12:49:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20616 for ; Fri, 14 Jan 2000 12:49:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6B99760@standards.nortelnetworks.com>; Fri, 14 Jan 2000 12:35:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124288 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 12:33:30 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2A74D1E0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 12:23:30 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA25043 for ; Fri, 14 Jan 2000 12:34:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA08404 for ; Fri, 14 Jan 2000 12:34:18 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 12:31:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087C5@whq-msgusr-02.fore.com> Date: Fri, 14 Jan 2000 12:34:15 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: New Version of Megaco/H.248 Protocol Document Available To: MEGACO@STANDARDS.NORTELNETWORKS.COM We have posted a new version of the protocol document on the web site. Files are at ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc and ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf This version will, we hope, be superceded VERY soon by another one, and that one will be issued as an Internet Draft. This version has almost all of the text changes that have been discussed, an updated ABNF and updated examples. The ASN.1 is NOT updated. I would personally view the Signals text as not updated, and the Local/Remote descriptor text as still a work in progress. While there are some minor points still in debate, I believe most other issues are settled, and the text reflects the decisions made. Please review this text as soon as possible. If you believe that the text does not reflect consensus as determined in meetings and on the list, please raise the issues NOW. At this time, we are discouraging new ideas. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 13:41:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21106 for ; Fri, 14 Jan 2000 13:41:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F0E99D0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 13:30:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124472 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 13:29:54 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.714F7760@standards.nortelnetworks.com>; Fri, 14 Jan 2000 13:29:54 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 12:40:18 -0600 Received: from zrchb213.us.nortel.com by zmers013; Fri, 14 Jan 2000 13:39:58 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 12:39:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5EBE.BF115BAA" Message-ID: Date: Fri, 14 Jan 2000 12:39:49 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: POSTED: Draft Megaco/H.248 v13 X-To: Tom-PT Taylor , "brosen@fore.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5EBE.BF115BAA Content-Type: text/plain V13 is still missing the edits to the ASN.1 - these edits will be put in early next week, and an updated version will be posted then. In the meantime, here is V13. I tried to create a changebarred version against v12, but it wouldn't work for me. Files are at ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc and ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Friday, January 14, 2000 10:29 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Draft Megaco/H.248 v13 > > Brian and Nancy are about to put out a draft version of the protocol > document on the Megaco working website -- Nancy can announce the file > name. > This document is in an inconsistent state. We are hoping to clean up by > tonight, but I am aware that people have to have the latest available > information in order to prepare contributions for the US ITU process > meeting > on Tuesday. Please keep an eye on the list today and feel free to step in > yourself, to bring this work to a close. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > ------_=_NextPart_001_01BF5EBE.BF115BAA Content-Type: text/html Content-Transfer-Encoding: quoted-printable POSTED: Draft Megaco/H.248 v13

        V13 is still missing = the edits to the ASN.1 - these edits will be put in early next week, = and an updated version will be posted then. In the meantime, here is = V13.  I tried to create a changebarred version against v12, but it = wouldn't work for me.

        Files are at
        ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.doc
        and
        ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.pdf

        Nancy
        -----------------------------------------------------------------= ---------
        Nancy M. Greene
        Internet & Service = Provider Networks, Nortel Networks
        T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

          ----------
          From:   = Taylor, Tom-PT = [CAR:B904:EXCH]
          Sent:   = Friday, January 14, 2000 10:29 = AM
          To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject: =        Draft Megaco/H.248 v13

          Brian and Nancy are about to put out a = draft version of the protocol
          document on the Megaco working = website -- Nancy can announce the file name.
          This document is in an inconsistent = state.  We are hoping to clean up by
          tonight, but I am aware that people = have to have the latest available
          information in order to prepare = contributions for the US ITU process meeting
          on Tuesday.  Please keep an eye = on the list today and feel free to step in
          yourself, to bring this work to a = close.

          Tom Taylor
          Advisor -- IPConnect Standards
          E-mail: taylor@nortelnetworks.com = (internally, Tom-PT Taylor)
          Phone and FAX: +1 613 736 0961

        ------_=_NextPart_001_01BF5EBE.BF115BAA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 16:10:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22410 for ; Fri, 14 Jan 2000 16:10:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3990A280@standards.nortelnetworks.com>; Fri, 14 Jan 2000 15:58:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124542 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 15:56:42 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3533850@standards.nortelnetworks.com>; Fri, 14 Jan 2000 15:56:42 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 15:06:29 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 16:06:20 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 16:06:21 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 16:06:17 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: [Fwd: FW: Application for port-number] X-To: "Rosen, Brian" , Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM To start with, there's a difference between TCP and UDP. In TCP, once someone has connected to a TCP, no one else can. Hence the MGC has to tell the MG to back off and use another. When the MG does that, the MG end of the connection is fixed, just as it was the first time, so there's no point in the MG passing a contact address to the MGC. With UDP, the MGC has the option of providing an alternate port or not, depending on implementation: the option is there for everyone to use the same port. Moreover, the MGC has to know where to send the reply to the MG, since it's not pre-determined, so the MG-supplied address and port do have an use. These considerations imply changes to sections 7.28 and section 9. I propose the following: Section 7.2.8: in the paragraph beginning: "A ServiceChange Command specifying the "Root" for the TerminationID ...", sentence currently reading: "Normally, the MG will specify the transport ServiceChangeAddress ...": replace the word "Normally" with the phrase "When the transport for the protocol requires separate specification of an address for each end of the association (e.g. when UDP is used), ..." Section 9: Take the last line of the first paragraph, beginning "For transport of the protocol over IP ..." and merge it with the next paragraph. That paragraph is all about IP. Rearrange the paragraph to read as follows: "For transport of the protocol over IP, MGCs shall implement both TCP and UDP/ALF, an MG shall implement TCP or UDP/ALF or both. The MG is provisioned with a DNS name or IP address of a primary and zero or more secondary MGCs (see section 7.2.8) that is the address the MG uses to send messages to the MGC. The initial ServiceChange message should be sent to port ???? if using TCP and port ???? if using UDP. The ServiceChange command contains a ServiceChangeAddress parameter. If TCP is used, the MG need not include this parameter, since it is implicit in the TCP connection set up between the MG and the MGC. The MGC will typically include this parameter in order to tell the MG to move to a new port. If the ServiceChange response does contain a transport address which is different from the one on which the MG initiated the connection, both ends must close the connection. The MG must then re-initiate the association to the address/port given in the MGC's response. If UDP/ALF is used, the ServiceChange Command from the MG must contain the ServiceChangeAddress parameter, so that the MGC knows where to send its messages. The MGC may include this parameter in its response, if it wishes to change the address and/or port to which the MG sends messages during the life of the association." > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@fore.com] > Sent: Friday, January 14, 2000 3:02 PM > To: 'Chuong Nguyen' > Cc: Taylor, Tom-PT [CAR:B904:EXCH] > Subject: RE: [Fwd: FW: Application for port-number] > > I had a long winded answer here, then went and talked to some of my > people, and now I > think I am thoroughly confused. > > So I'm going to ask the "question first principals" question - why do we > need any of this? > > There is exactly one control association between an MG and an MGC. The MG > is the client, > and it initiates the association. Therefore this circumstance is exactly > analogous to > the control channel of FTP, or of TELNET, etc. The MG sends its source > address and > desired port in the TCP SYN, addressed to the MGC at the well known port. > The MGC > replies with its source address and the well known port, and the MG's > address and its > desired port. Rules state that flows are differentiated by the 4-tuple > (Source Address, > Source Port, Destination Address, Destination Port), so why do we need a > port number > in the protocol? Same effect with UDP, right? > > And, as I understand it, putting port numbers in protocol messages screws > up NAT and > firewalls. > > Even if there were reasons why it looked like you needed multiple > associations (the Virtual MG for example), the MG must use separate port > numbers, and the tuple remains unique. The MGC > never initiates the connection, so there isn't a problem there. > > So, why are we doing this? > > Brian > > > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] > Sent: Friday, January 14, 2000 10:16 AM > To: Rosen, Brian > Subject: Re: [Fwd: FW: Application for port-number] > > > What Tom is saying below is that when MG registers with MGC, the > port # in the ServiceChange Request > is irrevalent. When MGC replies back with ServiceChangeReply and > specifies a port # in that reply, > MG is supposed to close the registration connection on the Megaco > TCP well known port# > and establishes a new connection with MGC using the MGC specified > port # in the ServiceChangeReply. > > That is one does not use a port # to send message from MG to MGC and > another port# to > to send message from MGC to MG. > That is MGC always tells MG what port# to use after registration. > MG never tells MGC what > port # to use after registration. > Somehow this all make sense for TCP due to all the extra TCP connect > and accept stuffs. > > For UDP, one does not have the overhead of TCP connection. > Therefore MGC and MG can specify > what port # they will be listening for message after registration. > > The standard wording implies that MG can specify a port# that it > wishes MGC to send message to MG. > Therefore MG will only be listening on this port# for this MGC > message. If MG does not specify a port# > during registration, MG will listen on the Megaco UDP well known > port# for any future MGC message. > Likewise MGC can specify a port# that it wants the MG to send > message to MGC on. > Therefore MGC will only listen on the specified port# for that MG > message. > > > > > "Rosen, Brian" wrote: > > I think its correct. I'm not sure I understand the problem > with identifying TCP vs UDP.I don't see the discrepancy in the present > wording. They both say that the MG specifiesan address & port for the MGC > to use in the first ServiceChange (which would be sent tothe address > specified in the provisioned primary and secondary MGCs and the > IANAallocated port number). The MGC replies with the address and port > number it wishes theMG to use. What am I missing?Brian > > -----Original Message----- > From: Chuong Nguyen [ > ] > Sent: Friday, January 14, 2000 9:28 AM > To: Brian Rosen > Subject: [Fwd: FW: Application for port-number] > Brian > > Is there a consensus as to who does a TCP connect > and TCP accept? > > MGC listen (TCP accept) on Megaco TCP default port > #. > MG does a TCP connect to MGC. > MGC accepts the connection. > > Also please read the following email between Tom and > me. > Do you have anu additional opinon? > > Thanks > Chuong > > Tom-PT Taylor wrote: > > > > We'll have to clean that up by distinguishing > between TCP and UDP. Thanks for making this point. > > -----Original Message----- > From: Chuong Nguyen > [SMTP:Chuong.Nguyen@usa.alcatel.com] > Sent: Wednesday, January 12, 2000 5:01 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Subject: Re: FW: Application for port-number > > Thanks for the response. > I like your response but Section 9. Transport: > "The ServiceChange command contains a > ServiceChangePort parameter. > The MG specifies the TCP/UDP port number it wishes > the MGC to use for communication. > The MGC replies with the Port set to the TCP/UDP > port number it wishes the MG to uss for > further communications." > > Section 7.2.8 ServiceChange > "Normally, the MG will specify the transport > ServiceChangeAddress to be used by the MGC > for sending messages in the ServiceChangeAddress > parameter in the input ServiceChangeDescriptor. > The MGC specifies the ServiceChangeAddress for the > MG to use in the returned result > ServiceDescriptor." > > Chuong > > Tom-PT Taylor wrote: > > > > You have the wrong end of the conversation. > The MG port is irrelevant, since the MG is the one to initiate the > association. The sequence is: > > (1) MG connects to MGC at the well-known > port, sends a ServiceChange. > (2) The MGC sends back an alternate address/port. > (3) The MG breaks the connection and connects to the > new address/port supplied by the MGC. > > -----Original Message----- > From: Chuong Nguyen > [SMTP:Chuong.Nguyen@usa.alcatel.com] > Sent: Wednesday, January 12, 2000 4:19 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Subject: Re: FW: Application for port-number > > > Description : > > This will be a rendezvous port through which the > Media Gateway registers > > its > > presence with a Media Gateway Controller. > Assignment of a well-known port > > > > simplifies administration of the Media Gateway and > Controller. > > > > The Media Gateway has the option to use either UDP > or TCP. The Media > > Gateway > > Controller has the option to assign an alternative > address and/or port for > > > > establishment of the association, but must respect > the initial choice of > > protocol. > > Tom > > I have the follwing sceanrio: > > MGC listen (TCP accept) on the > Megaco well know TCP port #. > MG does a TCP connect to that port #. > MGC accepts MG. > MG sends a ServiceChange to register with MGC with a > TCP port # set to another TCP port # > (not the Megaco TCP default port #). > What happens next? > 1) MGC send the ServiceChange Reply to MG via the > Megaco TCP port # connection. > Close that connection. Open a TCP socket on > the MG supplied TCP port# and do a TCP accept > and wait for MG to connect to that TCP port#. > After MG connects to that TCP port#, > MG will receive all future MGC message via > this port#. MG does not have to do another > ServiceChange. > 2) MGC close the Megaco TCP port# connection to MG. > Open a TCP socket on the MG supplied TCP port# > and do a TCP accept and wait for MG to connect > to that TCP port#. After MG connects to that > TCP port#, MG can wait for the ServiceChange Reply > from MGC on this port#. > 3) Something else. > > For UDP it is clear and no big deal > for MGC to send the ServiceChange Reply to MG using the > MG supplied UDP port#. No TCP connection > establishment problem. > > I hope you understand what I am > asking. > Can the Standard be clarifies so that TCP and UDP > follows the same registration sequence? > > Thanks > Chuong > > -- > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: > (972) 519-4613 > **** The opinions expressed are not those of > Alcatel USA, Inc **** > > > -- > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: > (972) 519-4613 > **** The opinions expressed are not those of > Alcatel USA, Inc **** > > -- > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: > (972) 519-4613 > **** The opinions expressed are not those of > Alcatel USA, Inc **** > > > -- > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) > 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 16:28:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22516 for ; Fri, 14 Jan 2000 16:28:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1DE3600@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:16:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124566 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 16:15:33 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.95A3BB50@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:15:33 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 15:25:45 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 16:25:36 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 16:25:37 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 16:25:35 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Multiplexed Bearers X-To: Brian Rosen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I wanted to check my understanding of how multiplexed bearers (section 6.2 last paragraph) are supposed to work. Once created, they allow you to track the service state of the bearer. Do they do anything else for you? I can't see putting the derived terminations into the same context, because they might be involved in different calls. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 16:32:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22609 for ; Fri, 14 Jan 2000 16:32:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.51F40B70@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:20:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124585 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 16:19:51 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F512990@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:19:51 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 15:30:19 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 16:30:06 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 16:30:06 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 16:30:04 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: TerminationID X-cc: Brian Rosen To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 6.2.2, a TerminationID is characterized as "an arbitrary schema chosen by the MG". I'd suggest that the phrase "or provisioned by the operator" be added to that sentence, to cover the typical case. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 16:55:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22784 for ; Fri, 14 Jan 2000 16:55:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A0188A0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:43:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 16:42:36 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6C7D360@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:32:35 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA17606; Fri, 14 Jan 2000 16:43:19 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA08181; Fri, 14 Jan 2000 16:43:24 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 16:40:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087CC@whq-msgusr-02.fore.com> Date: Fri, 14 Jan 2000 16:43:20 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Multiplexed Bearers X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM The major thing they permit is a way to do a Subtract on the multiplexed bearer. The "derived" subchannels are not in the same context, as you observe. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Friday, January 14, 2000 4:26 PM > To: megaco@standards.nortelnetworks.com; Brian Rosen > Subject: Multiplexed Bearers > > > I wanted to check my understanding of how multiplexed bearers > (section 6.2 > last paragraph) are supposed to work. Once created, they > allow you to track > the service state of the bearer. Do they do anything else > for you? I can't > see putting the derived terminations into the same context, > because they > might be involved in different calls. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 16:59:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22806 for ; Fri, 14 Jan 2000 16:59:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A3175C0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:47:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124611 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 16:46:57 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92D79BA0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 16:36:57 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA17947; Fri, 14 Jan 2000 16:47:41 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA09005; Fri, 14 Jan 2000 16:47:46 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 16:45:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087CD@whq-msgusr-02.fore.com> Date: Fri, 14 Jan 2000 16:47:40 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: TerminationID X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I actually think that the MG is built with a schema, and the operator provisions within the schema, but I don't really object to this change. Repeating a favorite of mine: provisioning is evil. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Friday, January 14, 2000 4:30 PM > To: megaco@standards.nortelnetworks.com > Cc: Brian Rosen > Subject: TerminationID > > > In section 6.2.2, a TerminationID is characterized as "an > arbitrary schema > chosen by the MG". I'd suggest that the phrase "or provisioned by the > operator" be added to that sentence, to cover the typical case. > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 18:28:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23791 for ; Fri, 14 Jan 2000 18:28:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91EB5E80@standards.nortelnetworks.com>; Fri, 14 Jan 2000 18:17:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124745 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 18:15:40 -0500 Received: from sj-mailhub-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CEAF2E0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 18:15:40 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA08405; Fri, 14 Jan 2000 15:29:06 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA21472; Fri, 14 Jan 2000 15:26:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14463.45214.479051.241777@thomasm-u1.cisco.com> Date: Fri, 14 Jan 2000 15:26:22 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: FW: Application for port-number X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: > Further to this point, I would propose the following modification to section > 7.2.9. Following the sentence "MGCs should support both encoding > formats.": add the sentence: "If an MGC does not support a given encoding > method, it MUST at least be able to recognize a ServiceChange command within > that encoding and be able to return an error reply indicating error 501 - > Not implemented." If you have different ports for text and binary (which I think is by far the most sensible), an MGC would just not listen on that port which would generate a host unreachable ICMP when the MG tried to send a message. If an MG sees that and has the capability to switch over, it would just look at the ECONNREFUSED and use that as the cue to try the other port/encoding. Seems a whole lot easier to me. Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 18:38:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23943 for ; Fri, 14 Jan 2000 18:38:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F95D09F0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 18:27:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124779 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 18:26:41 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6E2D070@standards.nortelnetworks.com>; Fri, 14 Jan 2000 18:26:41 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 17:37:21 -0600 Received: from zrchb213.us.nortel.com by zmers013; Fri, 14 Jan 2000 18:37:04 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 17:37:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5EE8.417C7F88" Message-ID: Date: Fri, 14 Jan 2000 17:37:00 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: POSTED: Draft Megaco/H.248 v13 X-To: "brosen@fore.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5EE8.417C7F88 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are now a .doc and a .pdf file that have the changes from v12 to = v13 marked: > = ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13d= if > f.doc and > = ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13d= if > f.pdf >=20 >=20 v12 is the white document up for decision at the ITU-T SG16 meeting in Geneva Feb 7-18, and v13 includes all updates since then, but it is not complete as it is missing the ASN.1 updates. Next week, I expect, the editors will have a new version that has the ASN.1 updated and a few = more corrections. Keep your eyes open... Nancy ------------------------------------------------------------------------= -- Nancy M. Greene=20 Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Friday, January 14, 2000 1:39 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: POSTED: Draft Megaco/H.248 v13 >=20 > V13 is still missing the edits to the ASN.1 - these edits will be put = in > early next week, and an updated version will be posted then. In the > meantime, here is V13.=A0 I tried to create a changebarred version = against > v12, but it wouldn't work for me.=20 >=20 > Files are at=20 > = ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc = > and=20 > = ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf = >=20 > Nancy=20 > = ------------------------------------------------------------------------= -- >=20 > Nancy M. Greene=20 > Internet & Service Provider Networks, Nortel Networks=20 > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com=20 >=20 > ----------=20 > From: =A0 Taylor, Tom-PT [CAR:B904:EXCH]=20 > Sent: =A0 Friday, January 14, 2000 10:29 AM=20 > To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM=20 > Subject: =A0=A0=A0=A0=A0=A0 Draft Megaco/H.248 v13=20 >=20 > Brian and Nancy are about to put out a draft version of the protocol >=20 > document on the Megaco working website -- Nancy can announce the file > name.=20 > This document is in an inconsistent state.=A0 We are hoping to clean = up by=20 > tonight, but I am aware that people have to have the latest available = > information in order to prepare contributions for the US ITU process > meeting=20 > on Tuesday.=A0 Please keep an eye on the list today and feel free to = step in >=20 > yourself, to bring this work to a close.=20 >=20 > Tom Taylor=20 > Advisor -- IPConnect Standards=20 > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)=20 > Phone and FAX: +1 613 736 0961=20 >=20 >=20 ------_=_NextPart_001_01BF5EE8.417C7F88 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: POSTED: Draft Megaco/H.248 v13

        There are now a .doc = and a .pdf file that have the changes from v12 to v13 marked:

        ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v12to13diff.doc
        and
        ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v12to13diff.pdf


        v12 is the white = document up for decision at the ITU-T SG16 meeting in Geneva Feb 7-18, = and v13 includes all updates since then, but it is not complete as it = is missing the ASN.1 updates. Next week, I expect, the editors will = have a new version that has the ASN.1 updated and a few more = corrections. Keep your eyes open...

        Nancy
        -----------------------------------------------------------------= ---------
        Nancy M. Greene
        Internet & Service = Provider Networks, Nortel Networks
        T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

          ----------
          From:   = Greene, Nancy-M = [CAR:5N10:EXCH]
          Sent:   = Friday, January 14, 2000 1:39 = PM
          To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject: =        POSTED: Draft Megaco/H.248 v13

          V13 is still missing = the edits to the ASN.1 - these edits will be put in early next week, = and an updated version will be posted then. In the meantime, here is = V13.=A0 I tried to create a changebarred version against v12, but it = wouldn't work for me.

          Files are = at
          ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.doc
          and
          ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.pdf

          Nancy
          -----------------------------------------------------------------= ---------
          Nancy M. Greene=20
          Internet & Service = Provider Networks, Nortel Networks
          T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

                  ----------
          From: =A0 Taylor, Tom-PT [CAR:B904:EXCH] =
          Sent: =A0 Friday, January 14, 2000 10:29 AM =
          To: =A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM =
          Subject: =A0=A0=A0=A0=A0=A0 Draft Megaco/H.248 v13

                  Brian and Nancy are about to put out a draft version of = the protocol
          document on the Megaco working = website -- Nancy can announce the file name.
          This document is in an inconsistent = state.=A0 We are hoping to clean up by =
          tonight, but I am aware that people = have to have the latest available
          information in order to prepare = contributions for the US ITU process meeting
          on Tuesday.=A0 Please keep an eye on = the list today and feel free to step in =
          yourself, to bring this work to a = close.

                  Tom Taylor
          Advisor -- IPConnect = Standards
          E-mail: taylor@nortelnetworks.com = (internally, Tom-PT Taylor)
          Phone and FAX: +1 613 736 = 0961


        ------_=_NextPart_001_01BF5EE8.417C7F88-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 19:54:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24246 for ; Fri, 14 Jan 2000 19:54:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99C8F4D0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 19:43:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124832 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 19:41:20 -0500 Received: from ftpbox.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EEE29C20@standards.nortelnetworks.com>; Fri, 14 Jan 2000 19:31:19 -0500 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (VWALL-IN-ftpbox 2.0) with ESMTP id RAA11123 for ; Fri, 14 Jan 2000 17:42:07 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id RAA08157 for ; Fri, 14 Jan 2000 17:42:07 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2650.21) id ; Fri, 14 Jan 2000 18:42:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1252" Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9AE38A3C@il27exm02.cig.mot.com> Date: Fri, 14 Jan 2000 18:42:05 -0600 Reply-To: Jones Stuart-FWJ100 Sender: "Media Gateway Control (megaco)" From: Jones Stuart-FWJ100 Subject: Meeting in Adelaide, Australia To: MEGACO@STANDARDS.NORTELNETWORKS.COM Has it been decided whether there will be a MEGACO meeting in Adelaide? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 21:32:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24720 for ; Fri, 14 Jan 2000 21:32:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.501DD2C0@standards.nortelnetworks.com>; Fri, 14 Jan 2000 21:21:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124880 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 21:19:38 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10489360@standards.nortelnetworks.com>; Fri, 14 Jan 2000 21:19:38 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 20:29:55 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 14 Jan 2000 21:29:52 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 21:29:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF5F00.676B4DEC" Message-ID: Date: Fri, 14 Jan 2000 21:29:51 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Meeting in Adelaide, Australia X-To: Jones Stuart-FWJ100 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5F00.676B4DEC Content-Type: text/plain Yes, I have requested one half-day slot. > -----Original Message----- > From: Jones Stuart-FWJ100 [SMTP:Stuart_Jones-FWJ100@EMAIL.MOT.COM] > Sent: Friday, January 14, 2000 7:42 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Meeting in Adelaide, Australia > > Has it been decided whether there will be a MEGACO meeting in Adelaide? ------_=_NextPart_001_01BF5F00.676B4DEC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Meeting in Adelaide, Australia

        Yes, I have = requested one half-day slot.

          -----Original Message-----
          From:   Jones Stuart-FWJ100 = [SMTP:Stuart_Jones-FWJ100@EMAIL.MOT.COM]
          Sent:   Friday, January 14, 2000 7:42 PM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = Meeting in Adelaide, = Australia

          Has it been decided whether there will = be a MEGACO meeting in Adelaide?

        ------_=_NextPart_001_01BF5F00.676B4DEC-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Jan 14 21:47:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25674 for ; Fri, 14 Jan 2000 21:47:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D2B0A20@standards.nortelnetworks.com>; Fri, 14 Jan 2000 21:36:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 124905 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 14 Jan 2000 21:34:58 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34B88230@standards.nortelnetworks.com>; Fri, 14 Jan 2000 21:34:58 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 20:45:47 -0600 Received: from zrchb213.us.nortel.com by zmers013; Fri, 14 Jan 2000 21:45:40 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Fri, 14 Jan 2000 20:45:38 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Fri, 14 Jan 2000 20:45:38 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: FW: Application for port-number To: MEGACO@STANDARDS.NORTELNETWORKS.COM Good point. And I'm thinking that the ServiceChange command itself is buried rather deeply in the message, so if we do stay with one port, the requirement should be softened to recognition of a Meggaco/H.248 message. So, is convenience worth the consumption of another port? > -----Original Message----- > From: Michael Thomas [SMTP:mat@cisco.com] > Sent: Friday, January 14, 2000 6:26 PM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: Application for port-number > > Tom-PT Taylor writes: > > Further to this point, I would propose the following modification to > section > > 7.2.9. Following the sentence "MGCs should support both encoding > > formats.": add the sentence: "If an MGC does not support a given > encoding > > method, it MUST at least be able to recognize a ServiceChange command > within > > that encoding and be able to return an error reply indicating error 501 > - > > Not implemented." > > If you have different ports for text and binary > (which I think is by far the most sensible), an > MGC would just not listen on that port which > would generate a host unreachable ICMP when the > MG tried to send a message. If an MG sees that > and has the capability to switch over, it would > just look at the ECONNREFUSED and use that as > the cue to try the other port/encoding. > > Seems a whole lot easier to me. > > Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Jan 15 01:00:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27953 for ; Sat, 15 Jan 2000 01:00:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5491A170@standards.nortelnetworks.com>; Sat, 15 Jan 2000 0:49:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 125099 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 15 Jan 2000 00:48:07 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.302C2800@standards.nortelnetworks.com>; Sat, 15 Jan 2000 0:48:07 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 14 Jan 2000 23:57:35 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Sat, 15 Jan 2000 00:57:28 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Sat, 15 Jan 2000 00:57:28 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Sat, 15 Jan 2000 00:57:25 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Editorial Comments On v13 X-To: Brian Rosen , "John Segers (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 6.2.4, table of descriptors: descriptions of Local and Remote are reversed. 7. Opening paragraph: commands affect terminations only. Context properties are modified through specification within actions -- something you may want to mention at the end of the paragraph, giving a forward reference to sec. 8. 7. AuditValue command summary: "Audit" should be AuditValue". 7.1.7 second para, add the sentence "If a termination is added to an existing context in sendOnly mode, it must be done in such a way that the other terminations in the context are unaware of the addition." 7.1.7 third para: say "empty descriptor" rather than "null descriptor" 7.1.7 fourth para: first sentence typo "selected" second sentence typo "in excess" 7.1.8 first para, last sentence: suggest it read: "In the binary encoding, the equivalent of individual SDP session descriptions is achieved by enclosing the relevant Annex C tag-value pairs within the Annex A 'group of properties' construct." 7.1.8: all following the sentence "The following rules of interpretation are provided to facilitate that negotiation." I apologize for reorganizing this stuff so much, but now that we have agreed that for Reserve set to "false" an empty descriptor has a different meaning from when Reserve is "true", the exposition is better organized by giving the logic for those two cases separately. The two "phases" shown in the current document were just to simplify exposition, but they have lost their value and should be forgotten. Moreover, when Reserve is "true", then contrary to current text, it seems to me that the MG should allocate the resources it needs to support the descriptor that had some content before allocating the leftovers to fill up the empty descriptor. In other words, when the MGC provides details these take priority over filling in the blanks. Based on these considerations I now suggest the following logic: ----------- A new setting of Local / Remote Descriptor completely replaces the previous setting of that descriptor in the MG. Thus to retain information from the previous setting the MGC must include that information in the new setting. If the MGC wishes to delete some information from the existing descriptor, it merely resends the descriptor (in a Modify command) with the unwanted information stripped out. The MG processes the Local and Remote descriptors differently depending on whether Reserve is "true" or "false". One common element to the two cases is the treatment of an omitted descriptor (where the identifying descriptor tag is absent from the command, as well as any content). An omitted descriptor shall be treated as if the MGC had provided a descriptor containing the previous setting of that descriptor. If there was no previous setting, the MG must assume that the MGC does not wish to commit resources to support a media flow in the corresponding direction. In addition, in both cases, if both Local and Remote are present but empty and the medium of the stream cannot be inferred (e.g. from other terminations supporting that streamId in the same context), the MG must return an error. If Reserve is true, the alternatives presented to the MG represent the policy of the MGC. The MG returns those alternatives its current capability will allow. The MG reserves the resources required to support any of the alternatives it returns in each descriptor that it can, according to the following rules: (a) Multiple session descriptions describe mutually exclusive alternatives. (b) If multiple encodings are specified within a single session description, they may all be used as the content of the media flow requires, but the first-listed encoding is the default for the session. (c) If the MG has insufficient resources to support all of the specified alternatives, it must if at all possible support at least one alternative each within Local and Remote. Subject to this constraint, it should allocate resources for alternatives according to the priorities set by the MGC, as follows: (1) Session descriptions in each descriptor are listed in decreasing order of priority. The MG must allocate resources one session description at a time, alternating between Local and Remote until it is no longer possible to make progress in one of the descriptors, then continuing in the other descriptor until no more allocations are possible. (2) If one of the descriptors supplied by the MGC is empty, then the MG must apply the rule of alternation stated above as if the MGC had specified that descriptor to be identical to the other one. If both descriptors are empty (but the medium to be encoded is known), the MG supplies and reserves resources for all of the possibilities it can support for both directions of flow. (d) The MG returns descriptors showing the session descriptions for which it has reserved resources. An empty returned descriptor indicates either that the MGC has not indicated a requirement to support that direction of flow (omitted descriptor, no previous setting), or else that the resources required to support what the MGC has requested were unavailable. In Remote, if the "send-to" address is unknown, the MG should provide a dummy address (such as an all-zeroes IP address and port) as a placeholder until the MGC provides the real address to be used. (e) The MG must be prepared to receive media encoded according to any one of the alternatives specified in Local as soon as it has responded to the transaction containing the command. If Reserve is false, or not present, then the MG must apply the following rules to resolve Local and Remote to a single alternative each: (a) In contrast to the previous case, if the MGC supplies an empty descriptor the MG assumes that no flow need be supported in the given direction. In this case or in the case of an omitted descriptor with no previous specification, the MG chooses the first alternative in the other descriptor which it can support. (b) If possible, the MG establishes a symmetric media flow (same coding in both directions) (c) Where multiple possibilities for symmetric flows exist, the MG gives priority according to the order of listing of alternatives in Local (d) If symmetric coding is not possible, the MG chooses the first alternative in Local for which it is able to support at least one alternative in Remote. Where it can support more than one alternative in Remote, it chooses the earliest-listed one. (e) If the MG is unable to support at least one Local and one Remote alternative, it returns Error 510 Insufficient Resources. ------------------ 7.1.9 default streamID: may want to say that default is 0 unless over-ridden by the event definition. Otherwise a lot of audio-related events will need explicit streamIDs. 7.1.11: similar remark 7.1.14 Digit maps: my attempt to explain the purpose of "L" and "S" within digit strings is clearly inconsistent with the example. Do we keep the idea of "L" as an indication that a long-duration digit is expected and forget about "S", or use them as the example intended, to indicate inter-digit timing for the next digit? 7.1.18 second para, first sentence is repeated -- delete the first instance In the para introducing the figures, should indicate that they are successive stages in the same example. 7.2.1, 7.2.2, 7.2.4: EventBuffer descriptor must appear as an input. 8. last para -- I still think local management should be notified if an application-level timer expires. At the least, it might maintain a counter which could trigger alarms if it grows too quickly. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 03:23:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28669 for ; Mon, 17 Jan 2000 03:23:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D91A090@standards.nortelnetworks.com>; Mon, 17 Jan 2000 3:11:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126544 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 03:09:41 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D56CEE30@standards.nortelnetworks.com>; Mon, 17 Jan 2000 2:59:13 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA14015 for ; Mon, 17 Jan 2000 14:08:23 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256869.002C51E9 ; Mon, 17 Jan 2000 13:34:05 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256869.002C50A9.00@sandesh.hss.hns.com> Date: Mon, 17 Jan 2000 13:37:20 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Audit Descriptor and AuditValue command discrepancy To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, The Audit Descriptor description says it can be empty but ABNF doesn't support that. The Audit command description shows Audit descriptor is not optional but auditRequest in ABNF means it is optional. When in AuditValue command ContextID is ALL and TerminationID is ROOT the TransactionRequest and TransactionReply will be of the form TransactionRequest(TransactionId { ALL { AuditValue... }, C2 { Command ... Command } }) TransactionReply(TransactionID { C1 { AuditValueToken EQUAL CtxToken ( terminationIDList / LBRKT errorDescriptor RBRKT ) ... }, C2 { AuditValueToken EQUAL CtxToken ( terminationIDList / LBRKT errorDescriptor RBRKT ) ... }, C3 { AuditValueToken EQUAL CtxToken ( terminationIDList / LBRKT errorDescriptor RBRKT ) ... }, ... ... C2 { Reponse ... Response } }) How it is possible to figure out when the responses for ALL case is ending ? Also it is specified that this case returns "List of all ContextIds" but it also returns TerminationIds Moreover, I think in this case any value other than empty in AuditDescriptor should be an error. Is my understanding correct ??? regards -Sachin Mittal Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 04:48:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29064 for ; Mon, 17 Jan 2000 04:48:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.705BA320@standards.nortelnetworks.com>; Mon, 17 Jan 2000 4:36:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126596 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 04:35:04 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37553FA0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 4:35:00 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA23187; Mon, 17 Jan 2000 15:44:08 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256869.00351517 ; Mon, 17 Jan 2000 15:09:48 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256869.003514C0.00@sandesh.hss.hns.com> Date: Mon, 17 Jan 2000 15:13:03 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: How many *s are allowed in Wildcard Termination Identifiers X-cc: arayhan@NORTELNETWORKS.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all According to the protocol there is no limit on the number of *s that can occur in the termination name. isnt it computational intensive if termination ids like *a* arrive? regards -Madhubabu Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 09:00:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01279 for ; Mon, 17 Jan 2000 09:00:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AC6BFD60@standards.nortelnetworks.com>; Mon, 17 Jan 2000 8:48:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 126760 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 08:47:19 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76C4CA70@standards.nortelnetworks.com>; Mon, 17 Jan 2000 8:47:19 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 17 Jan 2000 07:57:30 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 17 Jan 2000 08:57:23 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 08:57:23 -0500 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Mon, 17 Jan 2000 08:57:21 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Bearer Descriptions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Now that we have sorted out where media processing should be specified (in Local and Remote, not in LocalControl) I would like to sort out another piece of the puzzle: bearer descriptions. I use the term "bearer" with the thought that it can be generalized from its traditional usage in TDM networks, but perhaps I can say it deals with the specification of layers 1-3 of transport. My basic proposition is that bearer descriptions in this generalized sense should be provided as much as possible as properties in TerminationState (if the whole termination can be identified with one bearer) or LocalControl (where the bearer is stream-specific). Basically the analysis of where to put properties and what properties to put there has to be done separately for each bearer type. The results have to be reflected in individual bearer-specific packages. Since the necessary information is already specified in Annex C, those packages will have to have cross-references to Annex C for the binary encoding. (I would find dispersal of Annex C into the packages more logical, but that's a battle I lost half a year ago.) The basic bearer types we have dealt with up to now are analogue, DS-0, IP, ATM-AAL2, and ATM-other. It seems reasonable to view analogue and DS-0 bearers as 1-1 mappable to the terminations they support. Hence the relevant properties can go into TerminationState -- they apply to the termination as a whole. For DS-0 these properties include the sort of thing signalled in the Bearer Capability, Information Rate, and similar information elements. For analogue, I'm not sure if anything is required -- perhaps frequency range. Echo cancellation and gain have to go into LocalControl, because they are specific to audio streams. ATM and IP transport tend to be set up on a per-media flow basis (i.e. potentially with different characteristics by direction of flow, individually by stream). From my point of view, this is a real headache -- the logical conclusion is that they should be specified in Local and Remote. The truth is that it would be nice to reserve Local and Remote for media description, as I suggested above, so that we don't have to extend SDP to carry all sorts of bearer-related stuff it doesn't handle now. Anyway, the sort of thing I see as bearer-related is as follows: For IP: anything to do with QOS For ATM: all those parameters needed to specify channel characteristics. Really, how we handle all this stuff is still an open question. What do other people think: properties on a per-direction basis in LocalControl, or extend SDP to handle all of it in Local and Remote? Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 13:57:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05723 for ; Mon, 17 Jan 2000 13:57:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1449D0F0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 13:45:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127021 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 13:43:36 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA768080@standards.nortelnetworks.com>; Mon, 17 Jan 2000 13:43:36 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 17 Jan 2000 12:53:54 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Mon, 17 Jan 2000 13:53:41 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CL0BKG0W; Mon, 17 Jan 2000 13:53:38 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MSWKJ; Mon, 17 Jan 2000 13:53:40 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <65256869.003514C0.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38836595.E0A1ED0@americasm01.nt.com> Date: Mon, 17 Jan 2000 13:55:17 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: How many *s are allowed in Wildcard Termination Identifiers X-To: bmbabu@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit While the protocol does not limit "*" in a termination, discration should be used when more than one "*" is present. Your implementation could support all kind of "*" or support max of two or whatever. The MGC can figure out if the MG did a best effort matching or exact and issue a consequence transactions (IMO). Abdallah bmbabu@hss.hns.com wrote: > Hi all > According to the protocol there is no limit on the number of *s that can > occur in the termination > name. isnt it computational intensive if termination ids like *a* arrive? > regards > -Madhubabu > Hughes Software Systems. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 13:57:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05726 for ; Mon, 17 Jan 2000 13:57:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14B515E0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 13:45:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127014 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 13:44:01 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.83A48230@standards.nortelnetworks.com>; Mon, 17 Jan 2000 13:34:01 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA21901; Mon, 17 Jan 2000 13:44:55 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA24244; Mon, 17 Jan 2000 13:44:55 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 13:42:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087DB@whq-msgusr-02.fore.com> Date: Mon, 17 Jan 2000 13:44:50 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit Descriptor and AuditValue command discrepancy X-To: "samittal@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM We have been talking about this very thing. I believe empty Audit means send no Statistics when used in Subtract. It's also a way to get a no=op command if anyone wanted one. We will fix this one way or the other. Brian > -----Original Message----- > From: Sachin Mittal [mailto:samittal@hss.hns.com] > Sent: Monday, January 17, 2000 3:07 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Audit Descriptor and AuditValue command discrepancy > > > Hi all, > The Audit Descriptor description says it can be empty but > ABNF doesn't support > that. > The Audit command description shows Audit descriptor is not > optional but > auditRequest > in ABNF means it is optional. > > When in AuditValue command ContextID is ALL and TerminationID is ROOT > the TransactionRequest and TransactionReply will be of the form > TransactionRequest(TransactionId { > ALL { AuditValue... }, > C2 { Command ... Command } }) > TransactionReply(TransactionID { > C1 { AuditValueToken EQUAL CtxToken ( > terminationIDList / LBRKT > errorDescriptor RBRKT ) ... }, > C2 { AuditValueToken EQUAL CtxToken ( > terminationIDList / LBRKT > errorDescriptor RBRKT ) ... }, > C3 { AuditValueToken EQUAL CtxToken ( > terminationIDList / LBRKT > errorDescriptor RBRKT ) ... }, > ... > ... > C2 { Reponse ... Response } }) > How it is possible to figure out when the responses for ALL > case is ending ? > Also it is specified that this case returns "List of all > ContextIds" but it also > returns TerminationIds > Moreover, I think in this case any value other than empty in > AuditDescriptor > should be an error. > > Is my understanding correct ??? > > regards > -Sachin Mittal > Hughes Software Systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 14:11:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05976 for ; Mon, 17 Jan 2000 14:11:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2FE59E00@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:00:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127067 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 13:58:27 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84A98430@standards.nortelnetworks.com>; Mon, 17 Jan 2000 13:48:21 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA23259; Mon, 17 Jan 2000 13:59:13 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA27993; Mon, 17 Jan 2000 13:59:14 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 13:56:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087DD@whq-msgusr-02.fore.com> Date: Mon, 17 Jan 2000 13:59:07 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: How many *s are allowed in Wildcard Termination Identifiers X-To: "bmbabu@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM We have discussed this, and *'s can appear anywhere in a terminationId. I believe this is necessary to control output from wildcarded commands. I don't think it is a large processing problem. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@hss.hns.com] > Sent: Monday, January 17, 2000 4:43 AM > To: MEGACO@standards.nortelnetworks.com > Subject: How many *s are allowed in Wildcard Termination Identifiers > > > Hi all > According to the protocol there is no limit on the > number of *s that can > occur in the termination > name. isnt it computational intensive if termination ids like > *a* arrive? > regards > -Madhubabu > Hughes Software Systems. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 14:24:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06408 for ; Mon, 17 Jan 2000 14:24:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DEC5E0A0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:12:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127088 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 14:11:18 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.532F4730@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:01:17 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA24458; Mon, 17 Jan 2000 14:11:48 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA01159; Mon, 17 Jan 2000 14:11:49 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 17 Jan 2000 14:09:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF2087DF@whq-msgusr-02.fore.com> Date: Mon, 17 Jan 2000 14:11:38 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Bearer Descriptions X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm baffled. We went through the discussion of not trying to duplicate in LocalControl that which you can express in SDP and/or Annex C. Now you want to go back and do that again. I don't want to split this up again. If SDP is missing something, or Annex C, then that is the place to put it. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, January 17, 2000 8:57 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Bearer Descriptions > > > Now that we have sorted out where media processing should be > specified (in > Local and Remote, not in LocalControl) I would like to sort > out another > piece of the puzzle: bearer descriptions. I use the term > "bearer" with the > thought that it can be generalized from its traditional usage in TDM > networks, but perhaps I can say it deals with the > specification of layers > 1-3 of transport. > > My basic proposition is that bearer descriptions in this > generalized sense > should be provided as much as possible as properties in > TerminationState (if > the whole termination can be identified with one bearer) or > LocalControl > (where the bearer is stream-specific). Basically the > analysis of where to > put properties and what properties to put there has to be > done separately > for each bearer type. The results have to be reflected in individual > bearer-specific packages. Since the necessary information is already > specified in Annex C, those packages will have to have > cross-references to > Annex C for the binary encoding. (I would find dispersal of > Annex C into > the packages more logical, but that's a battle I lost half a > year ago.) > > The basic bearer types we have dealt with up to now are > analogue, DS-0, IP, > ATM-AAL2, and ATM-other. > > It seems reasonable to view analogue and DS-0 bearers as 1-1 > mappable to the > terminations they support. Hence the relevant properties can go into > TerminationState -- they apply to the termination as a whole. > For DS-0 > these properties include the sort of thing signalled in the Bearer > Capability, Information Rate, and similar information elements. For > analogue, I'm not sure if anything is required -- perhaps > frequency range. > Echo cancellation and gain have to go into LocalControl, > because they are > specific to audio streams. > > ATM and IP transport tend to be set up on a per-media flow basis (i.e. > potentially with different characteristics by direction of flow, > individually by stream). From my point of view, this is a > real headache -- > the logical conclusion is that they should be specified in > Local and Remote. > The truth is that it would be nice to reserve Local and > Remote for media > description, as I suggested above, so that we don't have to > extend SDP to > carry all sorts of bearer-related stuff it doesn't handle > now. Anyway, the > sort of thing I see as bearer-related is as follows: > > For IP: anything to do with QOS > > For ATM: all those parameters needed to specify channel > characteristics. > > Really, how we handle all this stuff is still an open > question. What do > other people think: properties on a per-direction basis in > LocalControl, or > extend SDP to handle all of it in Local and Remote? > > Tom Taylor > Advisor -- IPConnect Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 14:46:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07339 for ; Mon, 17 Jan 2000 14:46:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F678BE40@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:34:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127190 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 14:34:05 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.82369620@standards.nortelnetworks.com>; Mon, 17 Jan 2000 14:24:05 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id VAA03228 for ; Mon, 17 Jan 2000 21:35:00 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id VAA11695 for ; Mon, 17 Jan 2000 21:35:00 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id VAA21991 for ; Mon, 17 Jan 2000 21:34:59 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id VAA28368; Mon, 17 Jan 2000 21:34:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i References: <4FBEA8857476D311A03300204840E1CF2087C5@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Message-ID: <14467.28387.388771.509383@rama.research.nokia.com> Date: Mon, 17 Jan 2000 21:34:59 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Comments on Interim AH-within-MEGACO Description To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF2087C5@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit The authentication mechanism described in section 10.2 is still incomplete. It is not clear what "UDP" is (source port, destination port or protocol number). Also, the current text refers to "transaction" instead of "message". There is error in the number of the hex digits for pseudo header, too. The text does not address ASN.1 at all. I think that the easiest way to defined the AH procedure for ASN.1 is to use algorithm defined in RFC2402, i.e., include an authHeader with zero AuthData when the data is encoded, compute ICV, then use some heuristics to find AuthData and patch the BER encoding result. In order to avoid issues with different canonic encodings, I'd like to encode pseudoheader with PER, especially because in this case the PER encodings means just putting the values in a C structure like this: struct PseudoHeader { struct in_addr src_ip; struct in_addr dst_ip; unsigned short src_port; /* in network byte order */ unsigned short src_port; /* in network byte order */ unsigned char protocol; }; So, I propose following text to the end of second paragraph: -----8<-------------8<-------------8<-------------8<-------------8<----- ... This prevents spoofing of the IP addresses. To retain the same functionality, the ICV calculation should be performed across the entire message prepended by a synthesized IP header consisting of an 8-bit protocol number, a 32-bit source IP address, a 32-bit destination address, a 16-bit source port, and a 16-bit desctination port. In the case of text encoding, the pseudo header is encoded as 26 hex digits. In the case of ASN.1 encodings, the pseudo header is encoded using the packed encoding rules (PER) [X.691]. The pseudo header has abstract syntax as follows: PseudoHeader ::= SEQUENCE { src-ip OCTET STRING (SIZE(4)), dst-ip OCTET STRING (SIZE(4)), src-port INTEGER (0 .. 65535), dst-port INTEGER (0 .. 65535), protocol INTEGER (0 .. 255) } -----8<-------------8<-------------8<-------------8<-------------8<----- Best regards, Pekka Pessi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 16:11:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08915 for ; Mon, 17 Jan 2000 16:11:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC3B6760@standards.nortelnetworks.com>; Mon, 17 Jan 2000 15:59:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127323 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 15:58:14 -0500 Received: from rtp-mailhub-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8FB4960@standards.nortelnetworks.com>; Mon, 17 Jan 2000 15:58:13 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by rtp-mailhub-1.cisco.com (8.9.1a/8.9.1) with ESMTP id QAA09711; Mon, 17 Jan 2000 16:09:30 -0500 (EST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA21773; Mon, 17 Jan 2000 13:05:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <4FBEA8857476D311A03300204840E1CF2087C5@whq-msgusr-02.fore.com> <14467.28387.388771.509383@rama.research.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14467.33821.113219.962421@thomasm-u1.cisco.com> Date: Mon, 17 Jan 2000 13:05:31 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Comments on Interim AH-within-MEGACO Description X-To: Pekka.Pessi@nokia.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <14467.28387.388771.509383@rama.research.nokia.com> Content-Transfer-Encoding: 7bit A *much* better option is to not require AH at all, but instead use ESP. ESP has the ability to have an authentication header in it, and with NULL encryption you get the same functionality. ESP does not try to authenticate the IP header either, which in this particular case neatly avoids the problem of not knowing which interface will be picked, etc, etc. AH should be deprecated, IMO, and I just read this morning that Bruce Schneier is in favor of nuking it too. Mike Pekka Pessi writes: > The authentication mechanism described in section 10.2 is still > incomplete. It is not clear what "UDP" is (source port, destination > port or protocol number). Also, the current text refers to > "transaction" instead of "message". There is error in the number of > the hex digits for pseudo header, too. > > The text does not address ASN.1 at all. I think that the easiest way > to defined the AH procedure for ASN.1 is to use algorithm defined in > RFC2402, i.e., include an authHeader with zero AuthData when the > data is encoded, compute ICV, then use some heuristics to find > AuthData and patch the BER encoding result. > > In order to avoid issues with different canonic encodings, I'd like > to encode pseudoheader with PER, especially because in this case the > PER encodings means just putting the values in a C structure like > this: > > struct PseudoHeader { > struct in_addr src_ip; > struct in_addr dst_ip; > unsigned short src_port; /* in network byte order */ > unsigned short src_port; /* in network byte order */ > unsigned char protocol; > }; > > So, I propose following text to the end of second paragraph: > > -----8<-------------8<-------------8<-------------8<-------------8<----- > ... This prevents spoofing of the IP addresses. To retain the same > functionality, the ICV calculation should be performed across the entire > message prepended by a synthesized IP header consisting of an 8-bit protocol > number, a 32-bit source IP address, a 32-bit destination address, a 16-bit > source port, and a 16-bit desctination port. In the case of text encoding, > the pseudo header is encoded as 26 hex digits. > > In the case of ASN.1 encodings, the pseudo header is encoded using the > packed encoding rules (PER) [X.691]. The pseudo header has abstract syntax > as follows: > > PseudoHeader ::= SEQUENCE > { > src-ip OCTET STRING (SIZE(4)), > dst-ip OCTET STRING (SIZE(4)), > src-port INTEGER (0 .. 65535), > dst-port INTEGER (0 .. 65535), > protocol INTEGER (0 .. 255) > } > -----8<-------------8<-------------8<-------------8<-------------8<----- > > > Best regards, > Pekka Pessi > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 16:29:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09114 for ; Mon, 17 Jan 2000 16:29:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61E18190@standards.nortelnetworks.com>; Mon, 17 Jan 2000 16:17:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127354 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 16:16:30 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0908980@standards.nortelnetworks.com>; Mon, 17 Jan 2000 16:06:29 -0500 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA02342; Mon, 17 Jan 2000 23:17:25 +0200 (EET) Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA22676; Mon, 17 Jan 2000 23:17:23 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id ; Mon, 17 Jan 2000 15:17:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 17 Jan 2000 15:17:08 -0600 Reply-To: Melinda.Shore@NOKIA.COM Sender: "Media Gateway Control (megaco)" From: Melinda.Shore@NOKIA.COM Subject: Re: Comments on Interim AH-within-MEGACO Description X-To: mat@CISCO.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM > A *much* better option is to not require AH at > all, but instead use ESP. Remember, this is *AH-within-megaco*, so your objections don't really apply in this case. Not that I'm all that fond of this mechanism (I'm all for cramming real IPSec down everybody's throats for this application), but it sure beats ESP-within- megaco. Melinda From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Jan 17 17:36:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09876 for ; Mon, 17 Jan 2000 17:36:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1EFB8A0@standards.nortelnetworks.com>; Mon, 17 Jan 2000 17:24:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 127429 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 17 Jan 2000 17:23:24 -0500 Received: from sj-mailhub-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8EE18010@standards.nortelnetworks.com>; Mon, 17 Jan 2000 17:23:23 -0500 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id OAA27571; Mon, 17 Jan 2000 14:36:08 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA21781; Mon, 17 Jan 2000 14:32:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Message-ID: <14467.39053.632348.132176@thomasm-u1.cisco.com> Date: Mon, 17 Jan 2000 14:32:45 -0800 Reply-To: Michael Thomas Sender: "Media Gateway Control (megaco)" From: Michael Thomas Subject: Re: Comments on Interim AH-within-MEGACO Description X-To: Melinda.Shore@nokia.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Melinda.Shore@nokia.com writes: > > A *much* better option is to not require AH at > > all, but instead use ESP. > > Remember, this is *AH-within-megaco*, so your > objections don't really apply in this case. Not > that I'm all that fond of this mechanism (I'm all > for cramming real IPSec down everybody's throats > for this application), but it sure beats ESP-within- > megaco. Sure it does. I was aware that we were talking about AH within MEGACO, and still find no reason to not use an ESP header instead of an AH header. Given AH's added complications of having to take the immutable part of the IP header into account for the hash, that seems like even less reason to use AH. Not that I think that application layer ESP is all that great of an idea in comparison to using IPSec either. Mike From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Jan 18 16:32:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06199 for ; Tue, 18 Jan 2000 16:32:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C576850@standards.nortelnetworks.com>; Tue, 18 Jan 2000 16:21:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 128422 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 18 Jan 2000 16:20:01 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.78E6C490@standards.nortelnetworks.com>; Tue, 18 Jan 2000 16:10:00 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 18 Jan 2000 15:20:41 -0600 Received: from zcard015.ca.nortel.com by zmers013; Tue, 18 Jan 2000 16:20:23 -0500 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DFF5RS56; Tue, 18 Jan 2000 16:20:17 -0500 Received: from nortelnetworks.com (PMERY0H8 [47.190.16.180]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DFGAL969; Tue, 18 Jan 2000 16:20:16 -0500 X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <3833250F.D643D3F8@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3884D97F.3D521312@nortelnetworks.com> Date: Tue, 18 Jan 2000 16:22:07 -0500 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: digit map questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Sorry for the extreme delay in this response to the questions. I guess I must have overlooked this when it was first posted, but was asked recently by one of my colleagues if I would take a stab at answers since no one else had done so. Comments inline. "John A. Voelker" wrote: > A colleague asked me to place on the list some questions he had concerning digit > maps (from S7.1.13 of the h.248v12 draft): Would appreciate any > clarifications. > > John > =========================================================== > > 1. What is the correct operational model for the inter-digit timing > mechanism? > - One timer for the entire digitmap whose timeout interval is changed > by an L or an S in the digitmap, or > - Two timers that are reset following each digit and generate an "L" > or "S" when they expire? > The wording of rules 2 and 3 seems to imply the first, but then I'm > unclear on the use of "L" and "S" in the digitmap. Also, are there > situations where the conditions of both rules are true? Definitely the intent is the first model. I don't believe that there is a condition where both rules can apply. > > 2. This question assumes the first of the models listed above. If > several viable alternatives specify different inter-digit timeout > values, which one is used? For example, a "4" is received when the > digitmap is: > { [2-9]Lxxxxxx | [3-8]Sxxxxxx } This example digit map is non deterministic and therefore IMO not legal. However, if this map was used I believe the intended approach would be that the digit map patterns would be checked from left to right and therefore the first pattern and timer would apply. > > 3. What does the "." character indicate? It appears to perform the same > role as "*" in regular expressions, i.e. that it means 0 or more of the > immediately preceding digitPosition. The "." means collect and continue collecting until specified timeout or other end of dialing event occurs. > > 4. What are the semantic restrictions on syntactically correct > digitmaps? For example, it doesn't seem valid to have more than one L > or S in an alternative. I don't actually understand the question. Please clarify. Michael Brown From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 05:17:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25276 for ; Wed, 19 Jan 2000 05:17:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7664E10@standards.nortelnetworks.com>; Wed, 19 Jan 2000 5:06:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129094 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 05:05:32 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CFB4EFB0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 5:05:32 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id MAA05654; Wed, 19 Jan 2000 12:16:24 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id MAA28708; Wed, 19 Jan 2000 12:16:23 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id MAA18499; Wed, 19 Jan 2000 12:16:22 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id MAA30510; Wed, 19 Jan 2000 12:16:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i References: X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid Message-ID: <14469.36598.589335.763718@rama.research.nokia.com> Date: Wed, 19 Jan 2000 12:16:22 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Re: [Fwd: FW: Application for port-number] X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: >To start with, there's a difference between TCP and UDP. In TCP, once >someone has connected to a TCP, no one else can. I don't understand. >Hence the MGC has to tell >the MG to back off and use another. When the MG does that, the MG end of >the connection is fixed, just as it was the first time, so there's no point >in the MG passing a contact address to the MGC. Agreed. >With UDP, the MGC has the option of providing an alternate port or not, >depending on implementation: the option is there for everyone to use the >same port. Moreover, the MGC has to know where to send the reply to the MG, >since it's not pre-determined, so the MG-supplied address and port do have >an use. I agree with Brian. MGC can send all further messages back to the same IP address/port that was used to send the service change request. There is absolutely no need to specify a port number in ServiceChange. I propose that we zap the following text: >The ServiceChange command contains a ServiceChangeAddress parameter. If TCP >is used, the MG need not include this parameter, since it is implicit in the >TCP connection set up between the MG and the MGC. The MGC will typically include this parameter in order to tell the MG to move to a new port. Replace it with text as follows. The ServiceChange command or response may contain a ServiceChangeAddress parameter. The MGC can include this parameter in order to tell the MG to move to another MGC. Also, the last paragraph should be zapped: >If UDP/ALF is used, the ServiceChange Command from the MG must contain the >ServiceChangeAddress parameter, so that the MGC knows where to send its >messages. The MGC may include this parameter in its response, if it wishes >to change the address and/or port to which the MG sends messages during the >life of the association." Pekka >> -----Original Message----- >> From: Rosen, Brian [SMTP:brosen@fore.com] >> Sent: Friday, January 14, 2000 3:02 PM >> To: 'Chuong Nguyen' >> Cc: Taylor, Tom-PT [CAR:B904:EXCH] >> Subject: RE: [Fwd: FW: Application for port-number] >> I had a long winded answer here, then went and talked to some of my >> people, and now I >> think I am thoroughly confused. >> So I'm going to ask the "question first principals" question - why do we >> need any of this? >> There is exactly one control association between an MG and an MGC. The MG >> is the client, >> and it initiates the association. Therefore this circumstance is exactly >> analogous to >> the control channel of FTP, or of TELNET, etc. The MG sends its source >> address and >> desired port in the TCP SYN, addressed to the MGC at the well known port. >> The MGC >> replies with its source address and the well known port, and the MG's >> address and its >> desired port. Rules state that flows are differentiated by the 4-tuple >> (Source Address, >> Source Port, Destination Address, Destination Port), so why do we need a >> port number >> in the protocol? Same effect with UDP, right? >> And, as I understand it, putting port numbers in protocol messages screws >> up NAT and >> firewalls. >> Even if there were reasons why it looked like you needed multiple >> associations (the Virtual MG for example), the MG must use separate port >> numbers, and the tuple remains unique. The MGC >> never initiates the connection, so there isn't a problem there. >> So, why are we doing this? From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 07:34:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26930 for ; Wed, 19 Jan 2000 07:34:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA2A5570@standards.nortelnetworks.com>; Wed, 19 Jan 2000 7:22:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129159 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 07:21:12 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1EEA6B0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 7:21:09 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA27413 for ; Wed, 19 Jan 2000 17:56:35 +0530 (IST) (envelope-from hsanand@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <3885AE0C.8A0302A4@ficon-tech.com> Date: Wed, 19 Jan 2000 17:59:00 +0530 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Organization: Ficon Technology Subject: Comments on v13 draft To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Brian, Some editorial comments / issues on v13 draft: 1. In the v13 draft, there is no mention of audit of ephemeral terminations (Washington Issue #1). Has this idea been dropped ? 2. SDP related: - Details on the changes required in the SDP grammer (symbol to be used for wildcard etc.) are missing. - The specification should give details of the SDP fields (example network type, media type, transport type, any additional attributes) that would be used in MEGACOP. Similar information has been provided in MGCP and is useful for achieving interoperability. Similarly ATM bearer description in SDP should also be defined (or a pointer given to the relevant document). 3. For audit value what is the difference between ObservedEventsDescriptor and EventBuffer Descriptor. Only EventBuffer Descriptor should be sufficient. Similarly for Audit Capabilities, what would be returned in EventBufferDescriptor ? 4. Section 7.3: Error Codes 466, 467: There is no need of sending these error descriptors as these are supposed to be handled by the ALF and is not an error condition. 5. Sec 7.1.12: Audit Descriptor: Media Descriptor has been removed from the list of items that can be send in Audit Descriptor. However, it has not been removed from the ABNF rules (auditReturnParameter and auditItem). 6. Sec 7.1.12: Audit Descriptor: Event Buffer descriptor should be added to the table. 7. Sec 7.1.18: Second paragraph: "The Topology Descriptor precedes any commands within an action. ". However according to the ABNF rule, actionRequest, context properties can come only before the first command. 8. Sec 7.2.5: Audit Value: Second paragraph: "If the TerminationId is wildcarded, only one command return is generated, with the contents containing the union of the values of all Terminations matching the wildcard.". This can be rephrased as " If the command is wildcarded, ….". Same comment for Sec 7.2.6 9. Section 7.2.8: " 6. Failover – sent from MG to MGC to indicate the primary MG is out of service and a secondary MG is taking over." Failover is also used by MG when the MGC initiates switchover, in this Failover indicates that the active MGC is going out of service and it is redirecting MG to connect to a separate MGC. 10. Section 7.2.8: Summary of use of properties in the Service Descriptor: "Profile required if terminationID is not ROOT, optional otherwise". Shouldn't this be the other way round that is "Profile required if terminationID is ROOT, optional otherwise" 11. Section 8.2.2: "If a command is marked as optional, the MG has the choice of executing it or not, and if it does execute it, it returns the Response, or Error. " This line should be removed. ABNF related: 1. Sec 7.1.5; This section mentions that the properties can take a value CHOOSE. But the ABNF rule parmValue does not allow choose. 2. Sec 7.1.7: LocalControl Descriptor: reserve has been defined as a parameter to LocalControl Descriptor but is is missing in the ABNF. 3. Sec 7.1.14: The new text in DigitMap Descriptor section explains that the possible letters in the digit map string can be from A to k but the same has not been reflected in the ABNF. Regards, Harpreet _________________________________ Harpreet Singh Anand Ficon Technology E-mail : mailto:hsanand@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 07:57:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27569 for ; Wed, 19 Jan 2000 07:57:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.22737C10@standards.nortelnetworks.com>; Wed, 19 Jan 2000 7:45:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129190 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 07:44:32 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05DBFF00@standards.nortelnetworks.com>; Wed, 19 Jan 2000 7:44:31 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 06:54:06 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 19 Jan 2000 07:54:00 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jan 2000 07:54:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF627C.414D9FFA" Message-ID: Date: Wed, 19 Jan 2000 07:53:59 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: [Fwd: FW: Application for port-number] X-To: "Pekka.Pessi" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF627C.414D9FFA Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Pekka Pessi [SMTP:Pekka.Pessi@nokia.com] > Sent: Wednesday, January 19, 2000 5:16 AM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: [Fwd: FW: Application for port-number] > > Tom-PT Taylor writes: > >To start with, there's a difference between TCP and UDP. In TCP, once > >someone has connected to a TCP, no one else can. > > I don't understand. [[TomT]] Sorry -- wasn't thinking. This is a wrong statement. The reason the MGC might want to move the MG away from the contact port is more a matter of process relationships at the implementation level. > > >Hence the MGC has to tell > >the MG to back off and use another. When the MG does that, the MG end of > >the connection is fixed, just as it was the first time, so there's no > point > >in the MG passing a contact address to the MGC. > > Agreed. > > >With UDP, the MGC has the option of providing an alternate port or not, > >depending on implementation: the option is there for everyone to use the > >same port. Moreover, the MGC has to know where to send the reply to the > MG, > >since it's not pre-determined, so the MG-supplied address and port do > have > >an use. > > I agree with Brian. MGC can send all further messages back to the > same IP address/port that was used to send the service change > request. There is absolutely no need to specify a port number in > ServiceChange. [[TomT]] OK. > I propose that we zap the following text: > > >The ServiceChange command contains a ServiceChangeAddress parameter. If > TCP > >is used, the MG need not include this parameter, since it is implicit in > the > >TCP connection set up between the MG and the MGC. The MGC will typically > include this parameter in order to tell the MG to move to a new port. > > Replace it with text as follows. > > The ServiceChange command or response may contain a ServiceChangeAddress > parameter. The MGC can include this parameter in order to tell the MG to > move to another MGC. > > Also, the last paragraph should be zapped: > > >If UDP/ALF is used, the ServiceChange Command from the MG must contain > the > >ServiceChangeAddress parameter, so that the MGC knows where to send its > >messages. The MGC may include this parameter in its response, if it > wishes > >to change the address and/or port to which the MG sends messages during > the > >life of the association." > > Pekka > > >> -----Original Message----- > >> From: Rosen, Brian [SMTP:brosen@fore.com] > >> Sent: Friday, January 14, 2000 3:02 PM > >> To: 'Chuong Nguyen' > >> Cc: Taylor, Tom-PT [CAR:B904:EXCH] > >> Subject: RE: [Fwd: FW: Application for port-number] > > >> I had a long winded answer here, then went and talked to some of my > >> people, and now I > >> think I am thoroughly confused. > > >> So I'm going to ask the "question first principals" question - why do > we > >> need any of this? > > >> There is exactly one control association between an MG and an MGC. The > MG > >> is the client, > >> and it initiates the association. Therefore this circumstance is > exactly > >> analogous to > >> the control channel of FTP, or of TELNET, etc. The MG sends its source > >> address and > >> desired port in the TCP SYN, addressed to the MGC at the well known > port. > >> The MGC > >> replies with its source address and the well known port, and the MG's > >> address and its > >> desired port. Rules state that flows are differentiated by the 4-tuple > >> (Source Address, > >> Source Port, Destination Address, Destination Port), so why do we need > a > >> port number > >> in the protocol? Same effect with UDP, right? > > >> And, as I understand it, putting port numbers in protocol messages > screws > >> up NAT and > >> firewalls. > > >> Even if there were reasons why it looked like you needed multiple > >> associations (the Virtual MG for example), the MG must use separate > port > >> numbers, and the tuple remains unique. The MGC > >> never initiates the connection, so there isn't a problem there. > > >> So, why are we doing this? ------_=_NextPart_001_01BF627C.414D9FFA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Fwd: FW: Application for port-number]

          -----Original Message-----
          From:   Pekka Pessi [SMTP:Pekka.Pessi@nokia.com]
          Sent:   Wednesday, January 19, 2000 5:16 AM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]
          Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = Re: [Fwd: FW: Application for = port-number]

          Tom-PT Taylor = <taylor@NORTELNETWORKS.COM> writes:
          >To start with, there's a = difference between TCP and UDP.  In TCP, once
          >someone has connected to a TCP, = no one else can. 

                  I don't understand.
          [[TomT]] 
          Sorry -- wasn't = thinking.  This is a wrong statement.  The reason the MGC = might want to move the MG away from the contact port is more a matter = of process relationships at the implementation level.

                 =20
          >Hence the MGC has to tell
          >the MG to back off and use = another.  When the MG does that, the MG end of
          >the connection is fixed, just as = it was the first time, so there's no point
          >in the MG passing a contact = address to the MGC.

                  Agreed.
                 =20
          >With UDP, the MGC has the option = of providing an alternate port or not,
          >depending on implementation: the = option is there for everyone to use the
          >same port.  Moreover, the = MGC has to know where to send the reply to the MG,
          >since it's not pre-determined, so = the MG-supplied address and port do have
          >an use.

                  I agree with Brian. MGC can send all further messages = back to the
                  same IP address/port that was used to send the service = change
                  request. There is absolutely no need to specify a port = number in
                  ServiceChange.
          [[TomT]] 
          OK.

                  I propose that we zap the following text:

          >The ServiceChange command contains = a ServiceChangeAddress parameter.  If TCP
          >is used, the MG need not include = this parameter, since it is implicit in the
          >TCP connection set up between the = MG and the MGC.  The MGC will typically
          include this parameter in order to = tell the MG to move to a new port. 

                  Replace it with text as follows.

          The ServiceChange command or response = may contain a ServiceChangeAddress
          parameter.  The MGC can include = this parameter in order to tell the MG to
          move to another MGC.

                  Also, the last paragraph should be zapped:

          >If UDP/ALF is used, the = ServiceChange Command from the MG must contain the
          >ServiceChangeAddress parameter, = so that the MGC knows where to send its
          >messages.  The MGC may = include this parameter in its response, if it wishes
          >to change the address and/or port = to which the MG sends messages during the
          >life of the = association."

                  =         =         =         =         Pekka

          >> -----Original = Message-----
          >> From: Rosen, Brian = [SMTP:brosen@fore.com]
          >> Sent: Friday, January 14, = 2000 3:02 PM
          >> To:   'Chuong = Nguyen'
          >> Cc:   Taylor, = Tom-PT [CAR:B904:EXCH]
          >> = Subject:      RE: [Fwd: FW: Application for = port-number]

          >> I had a long winded answer = here, then went and talked to some of my
          >> people, and now I
          >> think I am thoroughly = confused.

          >> So I'm going to ask the = "question first principals" question - why do we
          >> need any of this?

          >> There is exactly one control = association between an MG and an MGC.  The MG
          >> is the client,
          >> and it initiates the = association.  Therefore this circumstance is exactly
          >> analogous to
          >> the control channel of FTP, = or of TELNET, etc.  The MG sends its source
          >> address and
          >> desired port in the TCP SYN, = addressed to the MGC at the well known port.
          >> The MGC
          >> replies with its source = address and the well known port, and the MG's
          >> address and its
          >> desired port.  Rules = state that flows are differentiated by the 4-tuple
          >> (Source Address,
          >> Source Port, Destination = Address, Destination Port), so why do we need a
          >> port number
          >> in the protocol?   = Same effect with UDP, right?

          >> And, as I understand it, = putting port numbers in protocol messages screws
          >> up NAT and
          >> firewalls.

          >> Even if there were reasons = why it looked like you needed multiple
          >> associations (the Virtual MG = for example), the MG must use separate port
          >> numbers, and the tuple = remains unique.  The MGC
          >> never initiates the = connection, so there isn't a problem there.

          >> So, why are we doing = this?

        ------_=_NextPart_001_01BF627C.414D9FFA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 08:27:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28316 for ; Wed, 19 Jan 2000 08:27:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.56128620@standards.nortelnetworks.com>; Wed, 19 Jan 2000 8:15:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129226 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 08:14:21 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CAE9A2A0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 8:04:21 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA14810; Wed, 19 Jan 2000 08:15:20 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA01905; Wed, 19 Jan 2000 08:15:21 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Jan 2000 08:12:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF627E.D7A273D4" Message-ID: <4FBEA8857476D311A03300204840E1CF2087EC@whq-msgusr-02.fore.com> Date: Wed, 19 Jan 2000 08:15:20 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: [Fwd: FW: Application for port-number] X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF627E.D7A273D4 Content-Type: text/plain; charset="iso-8859-1" One reason the MGC may wish to change ports is that the MGC may be implemented with more than one processor, or more than one IP interface. I'll adjust the words to allow it, but not "require" it. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, January 19, 2000 7:54 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: [Fwd: FW: Application for port-number] -----Original Message----- From: Pekka Pessi [SMTP:Pekka.Pessi@nokia.com] Sent: Wednesday, January 19, 2000 5:16 AM To: Taylor, Tom-PT [CAR:B904:EXCH] Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: [Fwd: FW: Application for port-number] Tom-PT Taylor writes: >To start with, there's a difference between TCP and UDP. In TCP, once >someone has connected to a TCP, no one else can. I don't understand. [[TomT]] Sorry -- wasn't thinking. This is a wrong statement. The reason the MGC might want to move the MG away from the contact port is more a matter of process relationships at the implementation level. >Hence the MGC has to tell >the MG to back off and use another. When the MG does that, the MG end of >the connection is fixed, just as it was the first time, so there's no point >in the MG passing a contact address to the MGC. Agreed. >With UDP, the MGC has the option of providing an alternate port or not, >depending on implementation: the option is there for everyone to use the >same port. Moreover, the MGC has to know where to send the reply to the MG, >since it's not pre-determined, so the MG-supplied address and port do have >an use. I agree with Brian. MGC can send all further messages back to the same IP address/port that was used to send the service change request. There is absolutely no need to specify a port number in ServiceChange. [[TomT]] OK. I propose that we zap the following text: >The ServiceChange command contains a ServiceChangeAddress parameter. If TCP >is used, the MG need not include this parameter, since it is implicit in the >TCP connection set up between the MG and the MGC. The MGC will typically include this parameter in order to tell the MG to move to a new port. Replace it with text as follows. The ServiceChange command or response may contain a ServiceChangeAddress parameter. The MGC can include this parameter in order to tell the MG to move to another MGC. Also, the last paragraph should be zapped: >If UDP/ALF is used, the ServiceChange Command from the MG must contain the >ServiceChangeAddress parameter, so that the MGC knows where to send its >messages. The MGC may include this parameter in its response, if it wishes >to change the address and/or port to which the MG sends messages during the >life of the association." Pekka >> -----Original Message----- >> From: Rosen, Brian [SMTP:brosen@fore.com] >> Sent: Friday, January 14, 2000 3:02 PM >> To: 'Chuong Nguyen' >> Cc: Taylor, Tom-PT [CAR:B904:EXCH] >> Subject: RE: [Fwd: FW: Application for port-number] >> I had a long winded answer here, then went and talked to some of my >> people, and now I >> think I am thoroughly confused. >> So I'm going to ask the "question first principals" question - why do we >> need any of this? >> There is exactly one control association between an MG and an MGC. The MG >> is the client, >> and it initiates the association. Therefore this circumstance is exactly >> analogous to >> the control channel of FTP, or of TELNET, etc. The MG sends its source >> address and >> desired port in the TCP SYN, addressed to the MGC at the well known port. >> The MGC >> replies with its source address and the well known port, and the MG's >> address and its >> desired port. Rules state that flows are differentiated by the 4-tuple >> (Source Address, >> Source Port, Destination Address, Destination Port), so why do we need a >> port number >> in the protocol? Same effect with UDP, right? >> And, as I understand it, putting port numbers in protocol messages screws >> up NAT and >> firewalls. >> Even if there were reasons why it looked like you needed multiple >> associations (the Virtual MG for example), the MG must use separate port >> numbers, and the tuple remains unique. The MGC >> never initiates the connection, so there isn't a problem there. >> So, why are we doing this? ------_=_NextPart_001_01BF627E.D7A273D4 Content-Type: text/html; charset="iso-8859-1" RE: [Fwd: FW: Application for port-number]
        One reason the MGC may wish to change ports is that the MGC may be implemented with more than one
        processor, or more than one IP interface.  I'll adjust the words to allow it, but not "require" it.
         
        Brian
        -----Original Message-----
        From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
        Sent: Wednesday, January 19, 2000 7:54 AM
        To: MEGACO@standards.nortelnetworks.com
        Subject: Re: [Fwd: FW: Application for port-number]



          -----Original Message-----
          From:   Pekka Pessi [SMTP:Pekka.Pessi@nokia.com]
          Sent:   Wednesday, January 19, 2000 5:16 AM
          To:     Taylor, Tom-PT [CAR:B904:EXCH]
          Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:        Re: [Fwd: FW: Application for port-number]

          Tom-PT Taylor <taylor@NORTELNETWORKS.COM> writes:
          >To start with, there's a difference between TCP and UDP.  In TCP, once
          >someone has connected to a TCP, no one else can. 

                  I don't understand.
          [[TomT]] 
          Sorry -- wasn't thinking.  This is a wrong statement.  The reason the MGC might want to move the MG away from the contact port is more a matter of process relationships at the implementation level.

                 
          >Hence the MGC has to tell
          >the MG to back off and use another.  When the MG does that, the MG end of
          >the connection is fixed, just as it was the first time, so there's no point
          >in the MG passing a contact address to the MGC.

                  Agreed.
                 
          >With UDP, the MGC has the option of providing an alternate port or not,
          >depending on implementation: the option is there for everyone to use the
          >same port.  Moreover, the MGC has to know where to send the reply to the MG,
          >since it's not pre-determined, so the MG-supplied address and port do have
          >an use.

                  I agree with Brian. MGC can send all further messages back to the
                  same IP address/port that was used to send the service change
                  request. There is absolutely no need to specify a port number in
                  ServiceChange.
          [[TomT]] 
          OK.

                  I propose that we zap the following text:

          >The ServiceChange command contains a ServiceChangeAddress parameter.  If TCP
          >is used, the MG need not include this parameter, since it is implicit in the
          >TCP connection set up between the MG and the MGC.  The MGC will typically
          include this parameter in order to tell the MG to move to a new port. 

                  Replace it with text as follows.

          The ServiceChange command or response may contain a ServiceChangeAddress
          parameter.  The MGC can include this parameter in order to tell the MG to
          move to another MGC.

                  Also, the last paragraph should be zapped:

          >If UDP/ALF is used, the ServiceChange Command from the MG must contain the
          >ServiceChangeAddress parameter, so that the MGC knows where to send its
          >messages.  The MGC may include this parameter in its response, if it wishes
          >to change the address and/or port to which the MG sends messages during the
          >life of the association."

                                                  Pekka

          >> -----Original Message-----
          >> From: Rosen, Brian [SMTP:brosen@fore.com]
          >> Sent: Friday, January 14, 2000 3:02 PM
          >> To:   'Chuong Nguyen'
          >> Cc:   Taylor, Tom-PT [CAR:B904:EXCH]
          >> Subject:      RE: [Fwd: FW: Application for port-number]

          >> I had a long winded answer here, then went and talked to some of my
          >> people, and now I
          >> think I am thoroughly confused.

          >> So I'm going to ask the "question first principals" question - why do we
          >> need any of this?

          >> There is exactly one control association between an MG and an MGC.  The MG
          >> is the client,
          >> and it initiates the association.  Therefore this circumstance is exactly
          >> analogous to
          >> the control channel of FTP, or of TELNET, etc.  The MG sends its source
          >> address and
          >> desired port in the TCP SYN, addressed to the MGC at the well known port.
          >> The MGC
          >> replies with its source address and the well known port, and the MG's
          >> address and its
          >> desired port.  Rules state that flows are differentiated by the 4-tuple
          >> (Source Address,
          >> Source Port, Destination Address, Destination Port), so why do we need a
          >> port number
          >> in the protocol?   Same effect with UDP, right?

          >> And, as I understand it, putting port numbers in protocol messages screws
          >> up NAT and
          >> firewalls.

          >> Even if there were reasons why it looked like you needed multiple
          >> associations (the Virtual MG for example), the MG must use separate port
          >> numbers, and the tuple remains unique.  The MGC
          >> never initiates the connection, so there isn't a problem there.

          >> So, why are we doing this?

        ------_=_NextPart_001_01BF627E.D7A273D4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 09:48:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29780 for ; Wed, 19 Jan 2000 09:48:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE2B50C0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 9:36:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129324 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 09:35:26 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D7A1B20@standards.nortelnetworks.com>; Wed, 19 Jan 2000 9:25:24 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id UAA29514 for ; Wed, 19 Jan 2000 20:00:55 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3885CBA5.E5D3F85A@ficon-tech.com> Date: Wed, 19 Jan 2000 20:05:18 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: Package version problem To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi! The information received by an MGC about the packages supported by any termination by means of an Audit contains just the package ids. Since it does not have information about the version of the package, MGC would not know about the exact package version being supported by the termination. Therefore I suggest that the audit command reply should have the package version number information along with the package id. Vikas Salota Ficon Technology E-mail: vsalota@ficon-tech.com Web: www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 10:08:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00371 for ; Wed, 19 Jan 2000 10:08:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A83B700@standards.nortelnetworks.com>; Wed, 19 Jan 2000 9:56:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129349 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 09:55:19 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4B092C80@standards.nortelnetworks.com>; Wed, 19 Jan 2000 9:55:18 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 09:04:46 -0600 Received: from zcard00m.ca.nortel.com by zmers013; Wed, 19 Jan 2000 10:04:14 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DGGJ65Y8; Wed, 19 Jan 2000 10:04:13 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id CJ8MS6SG; Wed, 19 Jan 2000 10:04:13 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <3885CBA5.E5D3F85A@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <3885D2D0.2E113472@americasm01.nt.com> Date: Wed, 19 Jan 2000 10:05:52 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Package version problem X-To: Vikas Salota To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Good point. We have discussed that and it has been fixed. Abdallah Rayhan Vikas Salota wrote: > Hi! > The information received by an MGC about the packages supported by any > termination by means of an Audit contains just the package ids. Since it > does not have information about the version of the package, MGC would > not know about the exact package version being supported by the > termination. > Therefore I suggest that the audit command reply should have the package > version number information along with the package id. > > Vikas Salota > Ficon Technology > E-mail: vsalota@ficon-tech.com > Web: www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 12:22:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02306 for ; Wed, 19 Jan 2000 12:22:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A2B6A50@standards.nortelnetworks.com>; Wed, 19 Jan 2000 12:10:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 129500 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 12:08:58 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F456AD00@standards.nortelnetworks.com>; Wed, 19 Jan 2000 12:08:53 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 11:19:43 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 19 Jan 2000 12:19:29 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jan 2000 12:19:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF62A1.56A32F58" Message-ID: Date: Wed, 19 Jan 2000 12:19:22 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: Package version problem To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF62A1.56A32F58 Content-Type: text/plain Here is the fix, taken from the latest version available at ftp://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf (or .doc) in Annex B, packagesDescriptor is defined as: packagesDescriptor = PackagesToken LBRKT packagesItem *(COMMA packagesItem) RBRKT packagesItem = NAME "-" UINT16 And in the example, Appendix A, in step 21, the reply to the AuditValue has the line, indicating that the MG supports nt pkg version 1 and rtp pkg version 1: Packages {nt-1, rtp-1}, Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Rayhan, Abdallah [CAR:5N00:EXCH] > Sent: Wednesday, January 19, 2000 10:05 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Package version problem > > Good point. We have discussed that and it has been fixed. > > Abdallah Rayhan > > Vikas Salota wrote: > > > Hi! > > The information received by an MGC about the packages supported by any > > termination by means of an Audit contains just the package ids. Since it > > does not have information about the version of the package, MGC would > > not know about the exact package version being supported by the > > termination. > > Therefore I suggest that the audit command reply should have the package > > version number information along with the package id. > > > > Vikas Salota > > Ficon Technology > > E-mail: vsalota@ficon-tech.com > > Web: www.ficon-tech.com > ------_=_NextPart_001_01BF62A1.56A32F58 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Package version problem

        Here is the fix, = taken from the latest version available at
        ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.pdf (or .doc)


        in Annex B, = packagesDescriptor is defined as:

        packagesDescriptor   = =3D PackagesToken LBRKT packagesItem 
                   &= nbsp;           = *(COMMA packagesItem) RBRKT

        packagesItem         =3D = NAME "-" UINT16

        And in the example, = Appendix A, in step 21, the reply to the AuditValue
        has the line, = indicating that the MG supports nt pkg version 1 and rtp pkg version = 1:

                  Packages = {nt-1, rtp-1},


        Nancy
        -----------------------------------------------------------------= ---------
        Nancy M. Greene
        Internet & Service = Provider Networks, Nortel Networks
        T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

          ----------
          From:   = Rayhan, Abdallah = [CAR:5N00:EXCH]
          Sent:   = Wednesday, January 19, 2000 10:05 = AM
          To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject: =        Re: Package version problem

          Good point. We have discussed that and = it has been fixed.

          Abdallah Rayhan

          Vikas Salota wrote:

          > Hi!
          > The information received by an = MGC about the packages supported by any
          > termination by means of an Audit = contains just the package ids. Since it
          > does not have information about = the version of the package, MGC would
          > not know about the exact package = version being supported by the
          > termination.
          > Therefore I suggest that the = audit command reply should have the package
          > version number information along = with the package id.
          >
          > Vikas Salota
          > Ficon Technology
          > E-mail: = vsalota@ficon-tech.com
          > Web: www.ficon-tech.com

        ------_=_NextPart_001_01BF62A1.56A32F58-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 15:19:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04717 for ; Wed, 19 Jan 2000 15:19:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4E325F80@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:17:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0061 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 15:17:06 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3EF37AE0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:17:06 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA15597 for ; Wed, 19 Jan 2000 12:18:27 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000119151122.00ac7a90@dogwood.cisco.com> Date: Wed, 19 Jan 2000 15:14:59 -0500 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Plan for moving forward with ITU SG16 and megaco? To: MEGACO@STANDARDS.NORTELNETWORKS.COM What is the current plan for moving forward for ITU SG16? Here is what I know so far: * SG16 is planning to approve H.248 at their meeting in February * No more contributions to SG16 can be submitted from the US. * A draft from megaco will be submitted as a rapporteur's contribution??? * SG16 Q14 will work on H.248 based on written contributions to produce a version on which the administrations will vote at the end of the meeting. This is as much as I know. Anyone else have more info? Thanks, Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 15:22:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04742 for ; Wed, 19 Jan 2000 15:22:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.963C2540@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:19:32 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0072 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 15:18:14 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.67875BC0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:18:14 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA15628; Wed, 19 Jan 2000 12:18:31 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000119151035.00aa7910@dogwood.cisco.com> Date: Wed, 19 Jan 2000 15:10:54 -0500 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: POSTED: Draft Megaco/H.248 v13 X-To: Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Has this draft been submitted to IETF as an I-D? Chip At 05:37 PM 1/14/00 -0600, Nancy-M Greene wrote: >There are now a .doc and a .pdf file that have the changes from v12 to v13 >marked: > >ftp://s >tandards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13diff.doc >and >ftp://s >tandards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13diff.pdf > >v12 is the white document up for decision at the ITU-T SG16 meeting in >Geneva Feb 7-18, and v13 includes all updates since then, but it is not >complete as it is missing the ASN.1 updates. Next week, I expect, the >editors will have a new version that has the ASN.1 updated and a few more >corrections. Keep your eyes open... > >Nancy >-------------------------------------------------------------------------- >Nancy M. Greene >Internet & Service Provider Networks, Nortel Networks >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >---------- From: Greene, Nancy-M [CAR:5N10:EXCH] Sent: Friday, >January 14, 2000 1:39 >PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: POSTED: >Draft Megaco/H.248 v13 > >V13 is still missing the edits to the ASN.1 - these edits will be put in >early next week, and an updated version will be posted then. In the >meantime, here is V13. I tried to create a changebarred version against >v12, but it wouldn't work for me. > >Files are >at >ft >p://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc and > >ft >p://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf > >Nancy >-------------------------------------------------------------------------- > Nancy M. Greene Internet & Service Provider Networks, Nortel >Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > ---------- From: Taylor, Tom-PT > [CAR:B904:EXCH] Sent: Friday, January 14, 2000 10:29 > AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Draft > Megaco/H.248 v13 > > Brian and Nancy are about to put out a draft version of the > protocol document on the Megaco working website -- Nancy can announce > the file name. This document is in an inconsistent state. We are hoping > to clean up by tonight, but I am aware that people have to have the > latest available information in order to prepare contributions for the > US ITU process meeting on Tuesday. Please keep an eye on the list today > and feel free to step in yourself, to bring this work to a close. > > Tom Taylor Advisor -- IPConnect Standards E-mail: > taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 > 613 736 0961 Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 15:31:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04884 for ; Wed, 19 Jan 2000 15:31:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD1C3F10@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:29:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0099 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 15:28:17 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEC6FAB0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 15:28:16 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 14:28:54 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 19 Jan 2000 15:28:41 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jan 2000 15:28:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF62BB.C5485DA6" Message-ID: Date: Wed, 19 Jan 2000 15:28:31 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: POSTED: Draft Megaco/H.248 v13 X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF62BB.C5485DA6 Content-Type: text/plain; charset="iso-8859-1" Chip, When v14 is ready (this week, Brian?), Brian Rosen will turn that one into an I-D and submit it to the IETF. v13 was inconsistent as Tom said - it did not have the ASN.1 updated. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Chip Sharp[SMTP:chsharp@cisco.com] > Sent: Wednesday, January 19, 2000 3:10 PM > To: Greene, Nancy-M [CAR:5N10:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: POSTED: Draft Megaco/H.248 v13 > > Has this draft been submitted to IETF as an I-D? > > Chip > > At 05:37 PM 1/14/00 -0600, Nancy-M Greene wrote: > > >There are now a .doc and a .pdf file that have the changes from v12 to > v13 > >marked: > > > >ftp:/ > /s > >tandards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13diff.doc > >and > >ftp:/ > /s > >tandards.nortelnetworks.com/megaco/docs/latest/MegacoH248v12to13diff.pdf > > > >v12 is the white document up for decision at the ITU-T SG16 meeting in > >Geneva Feb 7-18, and v13 includes all updates since then, but it is not > >complete as it is missing the ASN.1 updates. Next week, I expect, the > >editors will have a new version that has the ASN.1 updated and a few more > > >corrections. Keep your eyes open... > > > >Nancy > >------------------------------------------------------------------------- > - > >Nancy M. Greene > >Internet & Service Provider Networks, Nortel Networks > >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > >---------- From: Greene, Nancy-M [CAR:5N10:EXCH] Sent: Friday, > >January 14, 2000 1:39 > >PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: POSTED: > >Draft Megaco/H.248 v13 > > > >V13 is still missing the edits to the ASN.1 - these edits will be put in > >early next week, and an updated version will be posted then. In the > >meantime, here is V13. I tried to create a changebarred version against > >v12, but it wouldn't work for me. > > > >Files are > >at > > > ft > >p://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.doc > and > > > > > > ft > >p://standards.nortelnetworks.com/megaco/docs/latest/MegacoH248v13.pdf > > > >Nancy > >------------------------------------------------------------------------- > - > > Nancy M. Greene Internet & Service Provider Networks, Nortel > >Networks T:514-271-7221 (internal:ESN853-1077) > E:ngreene@nortelnetworks.com > > > > ---------- From: Taylor, Tom-PT > > [CAR:B904:EXCH] Sent: Friday, January 14, 2000 10:29 > > AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Draft > > Megaco/H.248 v13 > > > > Brian and Nancy are about to put out a draft version of the > > protocol document on the Megaco working website -- Nancy can announce > > the file name. This document is in an inconsistent state. We are > hoping > > to clean up by tonight, but I am aware that people have to have the > > latest available information in order to prepare contributions for the > > US ITU process meeting on Tuesday. Please keep an eye on the list > today > > and feel free to step in yourself, to bring this work to a close. > > > > Tom Taylor Advisor -- IPConnect Standards E-mail: > > taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 > > > 613 736 0961 > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > > ------_=_NextPart_001_01BF62BB.C5485DA6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: POSTED: Draft Megaco/H.248 v13

        Chip,

        When v14 is ready = (this week, Brian?), Brian Rosen will turn that one into an I-D and = submit it to the IETF. v13 was inconsistent as Tom said - it did not = have the ASN.1 updated.

        Nancy
        -----------------------------------------------------------------= ---------
        Nancy M. Greene
        Internet & Service = Provider Networks, Nortel Networks
        T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

          ----------
          From:   = Chip = Sharp[SMTP:chsharp@cisco.com]
          Sent:   = Wednesday, January 19, 2000 3:10 = PM
          To: =     Greene, = Nancy-M [CAR:5N10:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject: =        Re: POSTED: Draft Megaco/H.248 v13

          Has this draft been submitted to IETF = as an I-D?

          Chip

          At 05:37 PM 1/14/00 -0600, Nancy-M = Greene wrote:

          >There are now a .doc and a .pdf = file that have the changes from v12 to v13
          >marked:
          >
          ><ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v1>ftp://s =
          >tandards.nortelnetworks.com/megaco/docs/latest/Megaco= H248v12to13diff.doc
          >and
          ><ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v1>ftp://s =
          >tandards.nortelnetworks.com/megaco/docs/latest/Megaco= H248v12to13diff.pdf
          >
          >v12 is the white document up for = decision at the ITU-T SG16 meeting in
          >Geneva Feb 7-18, and v13 includes = all updates since then, but it is not
          >complete as it is missing the = ASN.1 updates. Next week, I expect, the
          >editors will have a new version = that has the ASN.1 updated and a few more
          >corrections. Keep your eyes = open...
          >
          >Nancy
          >----------------------------------= ----------------------------------------
          >Nancy M. Greene
          >Internet & Service Provider = Networks, Nortel Networks
          >T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com
          >----------  = From:   Greene, Nancy-M [CAR:5N10:EXCH]  = Sent:   Friday,
          >January 14, 2000 1:39
          >PM  = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  = Subject:        POSTED:
          >Draft Megaco/H.248 v13
          >
          >V13 is still missing the edits to = the ASN.1 - these edits will be put in
          >early next week, and an updated = version will be posted then. In the
          >meantime, here is V13.  I = tried to create a changebarred version against
          >v12, but it wouldn't work for = me.
          >
          >Files are
          >at
          ><ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.doc>ft =
          >p://standards.nortelnetworks.com/megaco/docs/latest/M= egacoH248v13.doc  and
           > <ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.pdf> =
          ><ftp://standards.nortelnetworks.com/megaco/docs/latest/= MegacoH248v13.pdf>ft =
          >p://standards.nortelnetworks.com/megaco/docs/latest/M= egacoH248v13.pdf
          >
          >Nancy
          >-----------------------------------------------------= ---------------------
           > Nancy M. Greene  = Internet & Service Provider Networks, Nortel
          >Networks  T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com
          >
          >         = ----------  From:   Taylor, Tom-PT
          > [CAR:B904:EXCH]  = Sent:   Friday, January 14, 2000 10:29
          > AM  = To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  = Subject:        Draft
          > Megaco/H.248 v13
          >
          >         = Brian and Nancy are about to put out a draft version of the
          > protocol  document on the = Megaco working website -- Nancy can announce
          > the file name.  This = document is in an inconsistent state.  We are hoping
          > to clean up by  tonight, = but I am aware that people have to have the
          > latest available  = information in order to prepare contributions for the
          > US ITU process meeting  on = Tuesday.  Please keep an eye on the list today
          > and feel free to step in  = yourself, to bring this work to a close.
          >
          >         Tom = Taylor  Advisor -- IPConnect Standards  E-mail:
          > taylor@nortelnetworks.com = (internally, Tom-PT Taylor)  Phone and FAX: +1
          > 613 736 0961

          Support NetAid!  http://www.netaid.org
          --------------------------------------------------=
          Chip = Sharp           &= nbsp;     Consulting Engineering
          Cisco = Systems           = ;   Telco Bio-region
          Reality - Love it or Leave it.  =         =        
          --------------------------------------------------=


        ------_=_NextPart_001_01BF62BB.C5485DA6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 19:20:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06709 for ; Wed, 19 Jan 2000 19:20:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0300D470@standards.nortelnetworks.com>; Wed, 19 Jan 2000 19:18:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0282 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 19:16:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C00A7EF0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 19:16:56 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 18:18:05 -0600 Received: from zcard00n.ca.nortel.com by zmers013; Wed, 19 Jan 2000 19:17:57 -0500 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id C3GKP9PK; Wed, 19 Jan 2000 19:17:57 -0500 Received: from long-1.corpwest.baynetworks.com (long-pc.corpwest.baynetworks.com [134.177.35.121]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id D1KSSHCR; Wed, 19 Jan 2000 16:17:54 -0800 X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.1.32.20000119161639.00781ee0@zsc4c006.corpwest.baynetworks.com> Date: Wed, 19 Jan 2000 16:16:39 -0800 Reply-To: Lyndon Ong Sender: "Media Gateway Control (megaco)" From: Lyndon Ong Subject: megaco and rsvp question To: MEGACO@STANDARDS.NORTELNETWORKS.COM Folks, MGCP had a few hooks in it for use of RSVP to reserve resources for the RTP stream. Has this been carried over to Megaco/H.248? I have not been able to find this in the H.248 spec, but I may have missed this. MGCP had two parameters in the local connection options, "t" for the TOS value to be used, and "r" for the service to be requested in RSVP ("g/cl/be" for guaranteed, controlled load and best effort, respectively). This would allow the MGC to direct the MG to send out RSVP PATH messages for the specified service (PATH and RESV need to be sent out from the sender and receiver, not from the MGC). This could go into a package as properties to be added to the Termination State descriptor. Alternatively, there is a proposal in SIP to have some hooks in SDP, although this is going between two terminals. Cheers, L. Ong From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Jan 19 20:13:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07075 for ; Wed, 19 Jan 2000 20:13:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D835AA0@standards.nortelnetworks.com>; Wed, 19 Jan 2000 20:11:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0352 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 19 Jan 2000 20:10:53 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4978AB60@standards.nortelnetworks.com>; Wed, 19 Jan 2000 20:10:53 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 19 Jan 2000 19:12:02 -0600 Received: from zrchb213.us.nortel.com by zmers013; Wed, 19 Jan 2000 20:11:55 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jan 2000 19:11:52 -0600 X-Mailer: Internet Mail Service (5.5.2448.0) Message-ID: Date: Wed, 19 Jan 2000 19:11:51 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Request To Publish Informational RFC From Working Group Megaco X-To: Scott Bradner X-cc: ietf-secretary@ietf.org To: MEGACO@STANDARDS.NORTELNETWORKS.COM I-D draft-ietf-megaco-reqs-10.txt has passed through Megaco WG Last Call with one comment of disagreement with the architecture implied in the NAS requirements section. This comment was rejected on the basis of previous discussion indicating that consensus lies with the document as it stands. I am requesting on behalf of Megaco that this document be published as an Informational RFC. P.S. This request would have come sooner had I realized how simple the process is. I was waiting for a free moment to reread "The Secret Handshake". Tom Taylor Advisor -- IPConnect Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 06:30:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24614 for ; Thu, 20 Jan 2000 06:30:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B5CC230@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:28:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0838 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 06:27:20 -0500 Received: from mailboy.huawei.com.cn (202.96.135.134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.66A657E0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:27:18 -0500 Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA29939 for ; Thu, 20 Jan 2000 19:24:24 +0800 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <20000120112424.AAA29939@q17326> Date: Thu, 20 Jan 2000 19:30:32 +0800 Reply-To: Qiu Xiuping Sender: "Media Gateway Control (megaco)" From: Qiu Xiuping To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24614 Hi, All . While reading MEGACO/H.248 version 13, I meet some questions. 1. In 6.2 “ Terminations may be created which represent multiplexed bearers, “ I don't understand what multiplexed bearer mean.. Will you please give a detailed example? 2. In 6.2.4 property may be declared as "Global" I don't know how to decalre a property as " Global", I read everything but find nothing more about it. And it is the same with the “ "Properties may be read-only or read/write "“ , there is no place to declare a property to be read-only. 3. In 7.1.8 Local and Remote Descriptors Local refers to the media received by the MG and Remote refers to the media sent by the MG. I think this sentence is misfortune to be typo error. :-) 4 In 7.1.9 Events Descriptor The MG shall send a Notify command to the MGC when it detects an event in the Events Descriptor. “ If so, what is the use of eventbuffer ? 5 In 7.2.5 AuditValue “. If the TerminationId is wildcarded, only one command return is generated, with the contents containing the union of the values of all Terminations matching the wildcard. This convention may reduce the volume of data required to audit a group of Terminations “ Will you please give me a example for union of the values of all Terminations matching the wildcard? 6. In 7.2.8 ServiceChange Restart – indicates that service will be restored on the specified Terminations after expiration of the ServiceChangeDelayThe MG should set serviceState to "inService" upon expiry of ServiceChangeDelay How to deal with the bad terminations ? They can not be in " inService "” of course. 7 In 8.2.2 TransactionReply “ If the end of a command cannot be reliably determined it will return 442 Syntax Error in Transaction as the reply to the last action it can parse.” It seems that "442 Syntax Error in Transaction" should be corrected to be " 442 Syntax Error in Command " :-) 8 In 8.2.3 TransactionPending If a duplicate request is received when pending, the responder may send a duplicate pending immediately, or continue waiting for its timer to trigger another Transaction Pending. My question is how to determine to choose which method? Regards, Xiuping Qiu _______________________________________________ Xiuping Qiu Huawei Technologies Co., Ltd. Mail to qiuxiuping@sz.huawei.com.cn Visit http://www.huawei.com.cn _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 07:02:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25320 for ; Thu, 20 Jan 2000 07:02:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1515A8E0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:00:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0870 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 06:58:53 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE766FA0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 6:58:50 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA21908 for ; Thu, 20 Jan 2000 17:24:42 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------392CC5E856DF2B24F974E803" Message-ID: <3886F8BE.E4D399DB@ficon-tech.com> Date: Thu, 20 Jan 2000 17:29:59 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: Questions on MEGACO To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------392CC5E856DF2B24F974E803 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Brian, 1. This is regarding mandatory parameters and was raised recently on the mailing list, but to which there was no reply. So I am resending the same. In section 7.1.1 "Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the command responder retaining the previous value for that parameter" Does that mean that none of the parameters in a descriptor are actually "mandatory" in the real sense of the term ? 2. Consider the situation of failure of an MGC and MGC handing off MG to a different MGC. Section 11.5 says that "When the MGC initiates a HandOff, the handover should be transparent to the operations on the Media Gateway. Transactions can be executed in any order, and could be in progress when the ServiceChange is executed. Accordingly, commands in progress continue, transaction replies are sent to the new MGC, and the MG should expect outstanding transaction replies from the new MGC. Since all connections should stay up." However there is some text in the ALF Section Annexe D, in D.1.4, which also talks about handoff and which says, "In order to account for the possibility of an undetected or in-progress "failover", we modify the classic algorithm so that if the Media Gateway receives a valid ServiceChange message announcing a failover, it will start transmitting outstanding commands to that new MGC. Responses to commands are still transmitted to the source address of the command." Can you please clarify what action actually needs to be taken, the one specified in section 11.5, where the transaction replies are sent to the new MGC Or the one specified in D.1.4., where the command responses are sent to the source address of the command ? Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com --------------392CC5E856DF2B24F974E803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Brian,
         
        1. This is regarding mandatory parameters and was raised recently on the mailing list, but to which there was no reply. So I am resending the same.
        In section 7.1.1
        "Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor)
        result in the command responder retaining the previous value for that parameter"
        Does that mean that none of the parameters in a descriptor are actually "mandatory" in the real sense of the term ?

        2. Consider the situation of failure of an MGC and MGC handing off MG to a different MGC.
        Section 11.5 says that
        "When the MGC initiates a HandOff, the handover should be transparent to the operations on the Media Gateway.  Transactions can be executed in any order, and could be in progress when the ServiceChange is executed.  Accordingly, commands in progress continue, transaction replies are sent to the new MGC, and the MG should expect outstanding transaction replies from the new MGC.  Since all connections should stay up."

        However there is some text in the ALF Section Annexe D, in D.1.4, which also talks about handoff and which says,
        "In order to account for the possibility of an undetected or in-progress "failover", we modify the classic algorithm so that if the Media Gateway receives a valid ServiceChange message announcing a failover, it will start transmitting outstanding commands to that new MGC.  Responses to commands are still transmitted to the source address of the command."

        Can you please clarify what action actually needs to be taken, the one specified in section 11.5, where the transaction replies are sent to the new MGC
            Or
        the one specified in D.1.4., where the command responses are sent to the source address of the command ?
         

        Regards,

        Shalini Philip
        Ficon Technology
        E-Mail : mailto:sphilip@ficon-tech.com
        Web    : http://www.ficon-tech.com
          --------------392CC5E856DF2B24F974E803-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 07:37:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26114 for ; Thu, 20 Jan 2000 07:37:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC4AFC90@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:35:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1004 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 07:33:25 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A13A9840@standards.nortelnetworks.com>; Thu, 20 Jan 2000 7:33:22 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA23871; Thu, 20 Jan 2000 17:58:45 +0530 (IST) (envelope-from hsanand@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <20000120112424.AAA29939@q17326> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38870010.E125C8E0@ficon-tech.com> Date: Thu, 20 Jan 2000 18:01:13 +0530 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Organization: Ficon Technology X-To: Qiu Xiuping To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello Qiu Xiuping, > > 1. In 6.2 “ Terminations may be created which represent multiplexed bearers, “ > > I don't understand what multiplexed bearer mean.. Will you please give a detailed example? The multiplexed bearer refers to the case when there are more than one stream with explicit multiplexing method. For example an ATM AAL2 is a multiplexed bearer that can have multiple AAL2 channels within it. For more details refer to the thread "Washington Issue 8 - Deleting Multiplexed Bearers" > 4 In 7.1.9 Events Descriptor > > The MG shall send a Notify command to the MGC when it detects an event in the Events Descriptor. “ > > If so, what is the use of eventbuffer ? Event buffer is used for buffering the events specified in EventBuffer descriptor. After sending the notify for the occurence of an event which had been mentioned in the Event Descriptor, the MG starts waiting for the events specified in the EventBuffer Descriptor (for the case when the EventBuffer flag is set to TRUE). Till MG receives a new EventDescriptor, it will buffer occurrence of all the events that have been specified in the EventBufferDescriptor. Thus the event buffer is used for storing the events specified in EventBuffer Descriptor and not the EventDescriptor. > 5 In 7.2.5 AuditValue “. > > If the TerminationId is wildcarded, only one command return is generated, with the contents containing the union > of the values of all Terminations matching the wildcard. This convention may reduce the volume of data required > to audit a group of Terminations “ > > Will you please give me a example for union of the values of all Terminations matching the wildcard? The only useful wildcard operation for AuditValue seems to be a wildcard audit of the packages. MGC can send a wild card AuditValue command having TerminationId as * and AuditDescriptor having only one audit item, viz Package Descriptor. In the reply, MG would send a send a single reply with termination id as * and a single package descriptor having the union of all the packages that are supported on all the terminations in the MG. > 6. In 7.2.8 ServiceChange > > Restart – indicates that service will be restored on the specified Terminations after expiration of the ServiceChangeDelay. The MG should set serviceState to "inService" upon expiry of ServiceChangeDelay > > How to deal with the bad terminations ? They can not be in " inService "” of course. I don't think you can do much about bad terminations. If the termination is bad then it will remain OutOfSerice. > 7 In 8.2.2 TransactionReply > > “ If the end of a command cannot be reliably determined it will return 442 Syntax Error in Transaction as the reply to the last action it can parse.” > > It seems that "442 Syntax Error in Transaction" should be corrected to be " 442 Syntax Error in Command " :-) > > 8 In 8.2.3 TransactionPending > > If a duplicate request is received when pending, the responder may send a duplicate pending immediately, > or continue waiting for its timer to trigger another Transaction Pending. > > My question is how to determine to choose which method? Choosing a paticular method is implementation dependent and with both the options the protocol should work without any problem. However, for the case where the TransactionPending is sent on receiving the duplicate request, an additional TransactionPending is getting sent. IMO, the approach of sending TransactionPending on timeout is simpler and results in less packets on the network. Regards, Harpreet _________________________________ Harpreet Singh Anand Ficon Technology E-mail : mailto:hsanand@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 08:39:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28038 for ; Thu, 20 Jan 2000 08:39:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A2D5300@standards.nortelnetworks.com>; Thu, 20 Jan 2000 8:37:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1082 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 08:35:48 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58FC17D0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 8:35:46 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id TAA25365; Thu, 20 Jan 2000 19:01:03 +0530 (IST) (envelope-from hsanand@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38870EAB.DCB7D97B@ficon-tech.com> Date: Thu, 20 Jan 2000 19:03:31 +0530 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Organization: Ficon Technology Subject: Example Call Flow in V13 X-To: ngreene@NORTELNETWORKS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Nancy, I have a few questions regarding the call flows given in Appendix A (v13 draft): 1. In Step 3, a modify command is being sent to MG1 to modify the properties of the analog termination A444 in the NULL context. In this message, a Local Descriptor, which specifies the media that is received on the analog termination from outside the Media gateway, is being sent. In this Local Descriptor, the network type is being specified as IN and the protocol as IP4. Similarly, the transport is being defined as RTP/AVP. How can the recive media on the analog termination can have network type as IN, protocol type IP4 and transport type RTP/AVP ? 2. In step 8, it has been mentioned that "There is also an embedded event to stop dialtone upon detection of the first digit. dd is the DTMF Detection package, and ce is the completion event." What is the embedded event which stops the dialtone ? Is it the 'ce' event ? It can't be the 'ce' event because 'ce' event by definition will be detected when the full dialled number (that matches the digit map) has been received and hence the dial tone would be stopped only when the full dialled number has been received. 3. In step 11, MG1 notifies the dialled string "16135551212". My question is how does this dialled string satisfies the dial plan: (0S| 00S|[1-7]xLxx|8Lxxxxxxx|#xxxxxxx|*xx|9L1xxxxxxxxxx|9L011x.S) Regards, Harpreet _________________________________ Harpreet Singh Anand Ficon Technology E-mail : mailto:hsanand@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 09:14:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29590 for ; Thu, 20 Jan 2000 09:14:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F779C00@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:12:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1111 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 09:10:25 -0500 Received: from mailboy.huawei.com.cn (202.96.135.134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D0DF620@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:10:20 -0500 Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA4273 for ; Thu, 20 Jan 2000 22:07:27 +0800 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <20000120140727.AAA4273@q17326> Date: Thu, 20 Jan 2000 22:13:33 +0800 Reply-To: Qiu Xiuping Sender: "Media Gateway Control (megaco)" From: Qiu Xiuping Subject: Wildcard Response To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA29590 Hi, Harpreet Singh Anand£¡ My comment is marked with Qiu At 00-1-20 18:01:00 you wrote£º The only useful wildcard operation for AuditValue seems to be a wildcard audit of the packages. MGC can send a wild card AuditValue command having TerminationId as * and AuditDescriptor having only one audit item, viz Package Descriptor. In the reply, MG would send a send a single reply with termination id as * and a single package descriptor having the union of all the packages that are supported on all the terminations in the MG. ***************************************************************************************************** Qiu : But wildcard operation is not not only useful for AuditValue really. It is useful for other commands also. Let's think of its common usage . I think the wildcard operation as below: 1. sends a command with all wildcard TerminationID 2. response for each wildcarded TerminationID TransactionReply { TransactionID , ActionReply { ContextID , CommandReply { TerminationID,............ TerminationID, ........... TerminationID, ........... ( the following parameters may be different) } In this kind of reply , TerminationID standars for wildcarded Termination case, The following parameters may be different. 3. Union Reply TransactionReply { TransactionID, ActionReply { ContextID , CommandReply { * , .................( the following parameters should be the same) } In this kind of reply , the TerminationID is * , standards for all TerminationID, but the result must be the same. My question is, if the following parameters are different. how can the reply be united ? Regards, Xiuping Qiu _______________________________________________ Xiuping Qiu Huawei Technologies Co., Ltd. Mail to qiuxiuping@sz.huawei.com.cn Visit http://www.huawei.com.cn _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 10:02:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01078 for ; Thu, 20 Jan 2000 10:02:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D66FAAA0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:22:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1133 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 09:20:34 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AAA0010@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:20:33 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 20 Jan 2000 08:21:36 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 20 Jan 2000 09:21:18 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 09:21:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6351.9D46D8F0" Message-ID: Date: Thu, 20 Jan 2000 09:21:15 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Plan for moving forward with ITU SG16 and megaco? X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6351.9D46D8F0 Content-Type: text/plain I will confirm this. Basically I hope that Brian and John can put out draft-ietf-megaco-protocol-05.txt next week as the basis for WG Last Call. This should also be the basis for the Rapporteur's delta submission to the SG 16 meeting. If Last Call reveals any problems, I would hope the fixes could be fed in to SG 16 via a Rapporteur's TD (Temporary Document). > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@CISCO.COM] > Sent: Wednesday, January 19, 2000 3:15 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Plan for moving forward with ITU SG16 and megaco? > > What is the current plan for moving forward for ITU SG16? > > Here is what I know so far: > * SG16 is planning to approve H.248 at their meeting in > February > * No more contributions to SG16 can be submitted from the > US. > * A draft from megaco will be submitted as a rapporteur's > contribution??? > * SG16 Q14 will work on H.248 based on written contributions > to > produce a version on which the administrations will vote > at the > end of the meeting. > > This is as much as I know. Anyone else have more info? > > Thanks, > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- ------_=_NextPart_001_01BF6351.9D46D8F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Plan for moving forward with ITU SG16 and megaco?

        I will confirm = this.  Basically I hope that Brian and John can put out = draft-ietf-megaco-protocol-05.txt next week as the basis for WG Last = Call.  This should also be the basis for the Rapporteur's delta = submission to the SG 16 meeting.  If Last Call reveals any = problems, I would hope the fixes could be fed in to SG 16 via a = Rapporteur's TD (Temporary Document).

          -----Original Message-----
          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
          Sent:   Wednesday, January 19, 2000 3:15 PM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = Plan for moving forward with ITU = SG16 and megaco?

          What is the current plan for moving = forward for ITU SG16?

          Here is what I know so far:
                  = *       SG16 is planning to approve H.248 = at their meeting in February
                  = *       No more contributions to SG16 can = be submitted from the US.
                  = *       A draft from megaco will be = submitted as a rapporteur's contribution???
                  = *       SG16 Q14 will work on H.248 based = on written contributions to
                   &nb= sp;      produce a version on which the = administrations will vote at the
                   &nb= sp;      end of the meeting.

          This is as much as I know.  = Anyone else have more info?

          Thanks,
          Chip
          Support NetAid!  = http://www.netaid.org
          --------------------------------------------------=
          Chip = Sharp           &= nbsp;     Consulting Engineering
          Cisco = Systems           = ;   Telco Bio-region
          Reality - Love it or Leave it.
          --------------------------------------------------=

        ------_=_NextPart_001_01BF6351.9D46D8F0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 10:02:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01080 for ; Thu, 20 Jan 2000 10:02:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A0F8DA0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:27:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 09:25:19 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44932980@standards.nortelnetworks.com>; Thu, 20 Jan 2000 9:25:19 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 20 Jan 2000 08:25:51 -0600 Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 20 Jan 2000 09:25:43 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id ; Thu, 20 Jan 2000 09:25:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF6352.3BE1880C" Message-ID: Date: Thu, 20 Jan 2000 09:25:40 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: megaco and rsvp question X-To: Lyndon Ong To: MEGACO@STANDARDS.NORTELNETWORKS.COM This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF6352.3BE1880C Content-Type: text/plain From our point of view, based on the brief exchange Brian Rosen and I had over specification of bearer characteristics in the Megaco protocol, the solution would be as follows: (1) The hooks for IP QOS mechanisms would be provided by the IP package. (2) These hooks would appear as SDP/Annex C extensions. (3) They would be carried in the Local and RemoteDescriptors. Similar considerations govern ATM-related QOS. > -----Original Message----- > From: Ong, Lyndon [SC1:470:EXCH] > Sent: Wednesday, January 19, 2000 7:17 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: megaco and rsvp question > > Folks, > > MGCP had a few hooks in it for use of RSVP to reserve resources for the > RTP > stream. Has this been carried over to Megaco/H.248? I have not been able > to find this in the H.248 spec, but I may have missed this. > > MGCP had two parameters in the local connection options, "t" for the TOS > value to be used, and "r" for the service to be requested in RSVP > ("g/cl/be" for guaranteed, controlled load and best effort, respectively). > This would allow the MGC to direct the MG to send out RSVP PATH messages > for the specified service (PATH and RESV need to be sent out from the > sender and receiver, not from the MGC). > > This could go into a package as properties to be added to the Termination > State descriptor. Alternatively, there is a proposal in SIP to have some > hooks in SDP, although this is going between two terminals. > > Cheers, > > L. Ong ------_=_NextPart_001_01BF6352.3BE1880C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: megaco and rsvp question

        From our point of = view, based on the brief exchange Brian Rosen and I had over = specification of bearer characteristics in the Megaco protocol, the = solution would be as follows:

         (1) The hooks = for IP QOS mechanisms would be provided by the IP package.
         (2) These = hooks would appear as SDP/Annex C extensions.
         (3) They = would be carried in the Local and RemoteDescriptors.

        Similar = considerations govern ATM-related QOS.

          -----Original Message-----
          From:   Ong, Lyndon [SC1:470:EXCH]
          Sent:   Wednesday, January 19, 2000 7:17 PM
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:       = megaco and rsvp question

          Folks,

          MGCP had a few hooks in it for use of = RSVP to reserve resources for the RTP
          stream.  Has this been carried = over to Megaco/H.248?  I have not been able
          to find this in the H.248 spec, but I = may have missed this.

          MGCP had two parameters in the local = connection options, "t" for the TOS
          value to be used, and "r" = for the service to be requested in RSVP
          ("g/cl/be" for guaranteed, = controlled load and best effort, respectively).
          This would allow the MGC to direct = the MG to send out RSVP PATH messages
          for the specified service (PATH and = RESV need to be sent out from the
          sender and receiver, not from the = MGC).

          This could go into a package as = properties to be added to the Termination
          State descriptor.  = Alternatively, there is a proposal in SIP to have some
          hooks in SDP, although this is going = between two terminals.

          Cheers,

          L. Ong

        ------_=_NextPart_001_01BF6352.3BE1880C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 10:32:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02896 for ; Thu, 20 Jan 2000 10:32:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58E78B20@standards.nortelnetworks.com>; Thu, 20 Jan 2000 10:30:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1182 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 10:28:51 -0500 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2499F4C0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 10:28:50 -0500 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA17052 for ; Thu, 20 Jan 2000 10:30:17 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA17031 for ; Thu, 20 Jan 2000 10:30:17 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA23882; Thu, 20 Jan 2000 16:30:00 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA23622; Thu, 20 Jan 2000 16:29:32 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <3885AE0C.8A0302A4@ficon-tech.com> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <38872987.C6B26B3F@lucent.com> Date: Thu, 20 Jan 2000 16:28:07 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Comments on v13 draft To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02896 Harpreet, I realize that I'm not Brian, but would like to comment on some of the points you raise nevertheless :) Cheers, John Harpreet Singh Anand wrote: > > Hello Brian, > > Some editorial comments / issues on v13 draft: > > 1. In the v13 draft, there is no mention of audit of ephemeral terminations > (Washington Issue #1). Has this idea been dropped ? I remember the lively discussions in Washington, but only part of the proposed resolution (a ROOT property). Tom and/or Brian may be able to take this one. > 2. SDP related: > > - Details on the changes required in the SDP grammer (symbol to be used for > wildcard etc.) are missing. > > - The specification should give details of the SDP fields (example network > type, media type, transport type, any > additional attributes) that would be used in MEGACOP. Similar information has > been provided in MGCP and is useful > for achieving interoperability. Similarly ATM bearer description in SDP should > also be defined (or a pointer given to > the relevant document). The usual mode of operation is that Brian handles the text/SDP related stuff and I focus on the binary. So, again, I call upon Brian to take up this question. > 3. For audit value what is the difference between ObservedEventsDescriptor and > EventBuffer Descriptor. Only > EventBuffer Descriptor should be sufficient. Similarly for Audit Capabilities, > what would be returned in > EventBufferDescriptor ? Yes, there's something strange here. How about this: - When EventBuffer descriptor is included in a request from MGC to MG, it indicates which events the MG must detect when no Events descriptor is active. - When an MG is audited by means of AuditValue, it returns events that are in the buffer in ObservedEvents descriptor - When an MG is audited by means of AuditValue, it returns the events that it will detect when no Events descriptor is active in EventBuffer descriptor. > 4. Section 7.3: Error Codes 466, 467: There is no need of sending these error > descriptors as these are supposed to be > handled by the ALF and is not an error condition. Does the ALF protect against the megaco application sending duplicate requests? > 5. Sec 7.1.12: Audit Descriptor: Media Descriptor has been removed from the > list of items that can be send in Audit > Descriptor. However, it has not been removed from the ABNF rules > (auditReturnParameter and auditItem). Actually, it seems that Media descriptor wasn't in the table in v12 either. I added it. > 6. Sec 7.1.12: Audit Descriptor: Event Buffer descriptor should be added to the > table. Yes. > 7. Sec 7.1.18: Second paragraph: "The Topology Descriptor precedes any commands > within an action. ". However > according to the ABNF rule, actionRequest, context properties can come only > before the first command. Uncareful use of language on my part. Change to "The Topology Descriptor precedes the commands of an action." ok? > 8. Sec 7.2.5: Audit Value: Second paragraph: "If the TerminationId is > wildcarded, only one command return is > generated, with the contents containing the union of the values of all > Terminations matching the wildcard.". This can be > rephrased as " If the command is wildcarded, ….". Same comment for Sec 7.2.6 I think you're right. How about "If a wildcarded response is requested, [...]"? > 9. Section 7.2.8: " 6. Failover – sent from MG to MGC to indicate the primary > MG is out of service and a secondary > MG is taking over." Failover is also used by MG when the MGC initiates > switchover, in this Failover indicates that the > active MGC is going out of service and it is redirecting MG to connect to a > separate MGC. Absolutely right. > 10. Section 7.2.8: Summary of use of properties in the Service Descriptor: > "Profile required if terminationID is not > ROOT, optional otherwise". Shouldn't this be the other way round that is > "Profile required if terminationID is > ROOT, optional otherwise" Yes. > 11. Section 8.2.2: "If a command is marked as optional, the MG has the choice of > executing it or not, and if it does > execute it, it returns the Response, or Error. " This line should be removed. Ok. > ABNF related: > > 1. Sec 7.1.5; This section mentions that the properties can take a value CHOOSE. > But the ABNF rule parmValue does > not allow choose. You're right. I'll leave it to the ABNF experts to deal with this. The ASN.1 allows CHOOSE value to be used. > 2. Sec 7.1.7: LocalControl Descriptor: reserve has been defined as a parameter > to LocalControl Descriptor but is is > missing in the ABNF. You're right. I'll leave it to the ABNF experts. ASN.1 is fixed. > 3. Sec 7.1.14: The new text in DigitMap Descriptor section explains that the > possible letters in the digit map string can > be from A to k but the same has not been reflected in the ABNF. You're right. I'll leave it to the ABNF experts. > Regards, > Harpreet > > _________________________________ > Harpreet Singh Anand > Ficon Technology > E-mail : mailto:hsanand@ficon-tech.com > Web : http://www.ficon-tech.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Jan 20 14:38:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13180 for ; Thu, 20 Jan 2000 14:38:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BFC509E0@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:36:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1349 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 14:34:51 -0500 Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C7AA110@standards.nortelnetworks.com>; Thu, 20 Jan 2000 14:24:50 -0500 Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id NAA21550 for ; Thu, 20 Jan 2000 13:26:16 -0600 (CST) Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id xma021496; Thu, 20 Jan 00 13:26:08 -0600 Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id NAA09570 for ; Thu, 20 Jan 2000 13:27:09 -0600 (CST) Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com (Netscape Messaging Server 3.6) with ESMTP id AAE4F8B for ; Thu, 20 Jan 2000 13:26:05 -0600 Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id NAA03126 for ; Thu, 20 Jan 2000 13:25:17 -0600 (CST) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA02080 for ; Thu, 20 Jan 2000 13:25:17 -0600 (CST) X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------651F0F05E675E6FA2ECE33E1" Message-ID: <3887611C.F78CE5AA@usa.alcatel.com> Date: Thu, 20 Jan 2000 13:25:17 -0600 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: ServiceChange To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------651F0F05E675E6FA2ECE33E1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian We have discussed ServiceChange methods before regarding registration. But I do not see any new clarification in v13. You have mention that the first message from MG to MGC should always be ServiceChange w/Restart. MGC will always have the option to deny service to registering MG. Section 11.5 Failure of MG "The MG should send a ServiceChange message with a "Failover" method and a "MGC directed change" reason to the designated MGC. If it fails to get a reply, or fails to see an Audit command consequently, it should behave as if it's MGC failed, and start contacting secondary MGCs." Why can't MG send ServiceChange w/Restart here since it is trying to register with the new MGC? The reason can be "Failover: MGC directed change"? Regardless of the ServiceChange method issue, does new MGC still has the option to deny service to this requesting MG even though this MG was directed by the failing MGC? If the answer is yes, what should the MG do - contact secondary MGC? Last quoted sentence, does the MG use Restart or Failure to contact secondary MGCs? There are really 2 methods for registration, Restart or Failover as being the first message from MG to MGC. Section 7.2.8 implies only one - Restart w/ROOT. Section 11.5 implies Failover w/ROOT. Section 7.2.8 ServiceChange "6. Failover - send from MG to MGC to indicate the primary MG is out service and a secondary MG is taking over." This matches section 11.4 but in section 11.5, this method is also used by MG to register with Primary or Secondary MGC. Does the text need to be cleaned or more clarification? Thanks Chuong -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------651F0F05E675E6FA2ECE33E1 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
        Brian
        We have discussed ServiceChange methods before regarding registration.
        But I do not see any new clarification in v13.
        You have mention that the first message from MG to MGC should always be
        ServiceChange w/Restart.  MGC will always have the option to deny
        service to registering MG.
        


        Section 11.5 Failure of MG
        


        "The MG should send a ServiceChange message with a "Failover" method
        


        and a "MGC directed change" reason to the designated MGC.  If it
        


        fails to get a reply, or fails to see an Audit command consequently,
        


        it should behave as if it's MGC failed, and start contacting
        


        secondary MGCs."
        


        Why can't MG send ServiceChange w/Restart here since it is trying to
        


        register with the new MGC?  The reason can be "Failover: MGC
        


        directed change"?
        


        Regardless of the ServiceChange method issue, does new MGC still has the
        


        option to deny service to this requesting MG even though this MG
        


        was directed by the failing MGC?  If the answer is yes, what should
        


        the MG do - contact secondary MGC?
        


        Last quoted sentence, does the MG use Restart or Failure to contact
        


        secondary MGCs?
        


        


        There are really 2 methods for registration, Restart or Failover
        


        as being the first message from MG to MGC.  Section 7.2.8 implies
        


        only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.
        


        


        Section 7.2.8 ServiceChange
        


        "6. Failover - send from MG to MGC to indicate the primary MG is out
        


        service and a secondary MG is taking over."
        


        This matches section 11.4 but in section 11.5, this method is also
        


        used by MG to register with Primary or Secondary MGC.
        


        


        Does the text need to be cleaned or more clarification?
        


        


        Thanks
        


        Chuong
        


        


        


        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------651F0F05E675E6FA2ECE33E1--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 20 16:49:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16053
	for ; Thu, 20 Jan 2000 16:49:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14766260@standards.nortelnetworks.com>; Thu, 20 Jan 2000 16:47:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1491 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 20 Jan 2000 16:46:42 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.87B811D0@standards.nortelnetworks.com>;
          Thu, 20 Jan 2000 16:36:41 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id PAA10100
          for ; Thu, 20 Jan 2000 15:38:08
          -0600 (CST)
Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0) id
          xma010054; Thu, 20 Jan 00 15:38:02 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id PAA12136 for
          ; Thu, 20 Jan 2000 15:37:59
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAB5C75 for
          ; Thu, 20 Jan 2000 15:37:59 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id PAA28177 for ; Thu, 20
          Jan 2000 15:37:27 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA02252
          for ; Thu, 20 Jan 2000 15:37:27
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------1A66B5D558CE9E7FAB091FED"
Message-ID:  <38878017.79A1E70D@usa.alcatel.com>
Date:         Thu, 20 Jan 2000 15:37:27 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      v13 example
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------1A66B5D558CE9E7FAB091FED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Nancy

In the example,

Step 16 is missing a Add reply for A5555.

Question about Subtract and Statistics.  I know a decision was made but
I could not find it in
the archive.  v13 does not clearly state what happens regarding Subtract
and Statisitcs.

Does Subtract always returns Statistics by default?
To not get Statisitcs, one would use
    Subtract=A5555{Audit{}}

The example implies Subtract does not return Statistics by default.  One
has to ask for it.
    Subtract=A5555{Audit{Statistics}} ,
    Subtract=A5556{Audit{Statistics}}

Maybe if your example could show one case where you get statistics and
not get statistics
on a Subtract, it will be very helpful.

It might be helpful in following the example if physical termination id
starts w/TDM or PHY, etc
and RTP termination id starts with RTP.


Thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------1A66B5D558CE9E7FAB091FED
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Nancy

        In the example,

        Step 16 is missing a Add reply for A5555.

        Question about Subtract and Statistics.  I know a decision was
made but I could not find it in

        the archive.  v13 does not clearly state what happens regarding
Subtract and Statisitcs.

        Does Subtract always returns Statistics by default?

        To not get Statisitcs, one would use

            Subtract=A5555{Audit{}}

        The example implies Subtract does not return Statistics by default. 
One has to ask for it.

            Subtract=A5555{Audit{Statistics}} ,

            Subtract=A5556{Audit{Statistics}}

        Maybe if your example could show one case where you get statistics and
not get statistics

        on a Subtract, it will be very helpful.

        It might be helpful in following the example if physical termination
id starts w/TDM or PHY, etc

        and RTP termination id starts with RTP.

         

        Thanks

        Chuong

        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------1A66B5D558CE9E7FAB091FED--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 04:10:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05612
	for ; Fri, 21 Jan 2000 04:10:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.207E79D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 4:08:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1763 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 04:06:50 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4825CD40@standards.nortelnetworks.com>; Fri, 21 Jan 2000 4:02:06
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA05853; Fri, 21 Jan
          2000 15:01:54 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          6525686D.00313445 ; Fri, 21 Jan 2000 14:27:26 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <6525686D.00313306.00@sandesh.hss.hns.com>
Date:         Fri, 21 Jan 2000 14:30:43 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Choose option with wild card termination name
X-cc:         Abdallah Rayhan 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi rayhan,list
     The Termination ID description given in the section 6.2.2 say that the
termination names can be specified which enables MG to choose a circuit
within a trunk group. The text grammar defined  for TerminatinID is as follows:

TerminationID = "ROOT" / pathNAME / "$" / "*"  and
pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" )
          ["@" pathDomainName ]

the pathNAME rule doesn't have any "$" in it which enable MG to identify that
its a wild card CHOOSE request. Can you clarify this query of mine.

regards
-Sachin Mittal


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 07:45:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08113
	for ; Fri, 21 Jan 2000 07:45:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3018A230@standards.nortelnetworks.com>; Fri, 21 Jan 2000 7:43:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1901 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 07:41:33 -0500
Received: from mailboy.huawei.com.cn (202.96.135.134) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EF8717B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          7:41:32 -0500
Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail
          Server v2.02) with SMTP id AAA23695 for
          ; Fri, 21 Jan 2000 20:38:41 +0800
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20000121123841.AAA23695@q17326>
Date:         Fri, 21 Jan 2000 20:44:49 +0800
Reply-To: Qiu Xiuping 
Sender: "Media Gateway Control (megaco)"
              
From: Qiu Xiuping 
Subject:      What's the difference between the Priority and Emergency
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,Brian and all

Two attributes of context are the priority and the emergency
Annex A describes the priority , but not the emergency.

I wander what's the difference between the priority and Emergency.
And how to use them.

Regards,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   qiuxiuping@sz.huawei.com.cn
Visit     http://www.huawei.com.cn
_______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 08:43:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09592
	for ; Fri, 21 Jan 2000 08:43:22 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BD3F670@standards.nortelnetworks.com>; Fri, 21 Jan 2000 8:41:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1934 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 08:39:56 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B28A2170@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          8:29:56 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          OAA03160; Fri, 21 Jan 2000 14:31:10 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id OAA12374;
          Fri, 21 Jan 2000 14:31:09 +0100
Received: from ericsson.com (kipe141.eraj.ericsson.se [147.214.68.141]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          OAA29368; Fri, 21 Jan 2000 14:31:08 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20000121123841.AAA23695@q17326>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38885F9C.DD14222B@ericsson.com>
Date:         Fri, 21 Jan 2000 14:31:08 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: What's the difference between the Priority and Emergency
X-To:         Qiu Xiuping 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Xiuping,

Priority and emergency are two different services. Emergency could be
used when you want to have an emergency (ie.911) call. The MG could
decide to release resources to let this through.

Priority is used like in the MLPP service in ISUP.

Annex A contains both the priority and emergency. Please see below.

ContextRequest ::= SEQUENCE
{
        priority        INTEGER(0..15) OPTIONAL,
        emergency       BOOLEAN OPTIONAL,
        topologyReq     SEQUENCE OF TopologyRequest OPTIONAL,
        ...
}

Cheers, Christian

Qiu Xiuping wrote:
>
> Hi,Brian and all
>
> Two attributes of context are the priority and the emergency
> Annex A describes the priority , but not the emergency.
>
> I wander what's the difference between the priority and Emergency.
> And how to use them.
>
> Regards,
> Xiuping Qiu
> _______________________________________________
>
> Xiuping Qiu
> Huawei Technologies Co., Ltd.
> Mail to   qiuxiuping@sz.huawei.com.cn
> Visit     http://www.huawei.com.cn
> _______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 09:04:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10086
	for ; Fri, 21 Jan 2000 09:04:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C40A8E0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 9:02:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1960 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 09:01:24 -0500
Received: from mailboy.huawei.com.cn (202.96.135.134) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.1761B9B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          9:01:23 -0500
Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail
          Server v2.02) with SMTP id AAA25630; Fri, 21 Jan 2000 21:58:32 +0800
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <20000121135832.AAA25630@q17326>
Date:         Fri, 21 Jan 2000 22:04:41 +0800
Reply-To: Qiu Xiuping 
Sender: "Media Gateway Control (megaco)"
              
From: Qiu Xiuping 
Subject:      Re: What's the difference between the Priority and Emergency
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10086

Hi, Christian Groves£¡

Yeah, You are right. :-)

But I still want to know if there is a context with priority = 15 or other level
and a context with emergency =1 , then which context should be served first.


At 00-1-21 14:31:00 you wrote£º
>Hello Xiuping,
>
>Priority and emergency are two different services. Emergency could be
>used when you want to have an emergency (ie.911) call. The MG could
>decide to release resources to let this through.
>
>Priority is used like in the MLPP service in ISUP.
>
>Annex A contains both the priority and emergency. Please see below.
>
>ContextRequest ::= SEQUENCE
>{
>	priority	INTEGER(0..15) OPTIONAL,
>	emergency	BOOLEAN OPTIONAL,
>	topologyReq	SEQUENCE OF TopologyRequest OPTIONAL,
>	...
>}
>
>Cheers, Christian
>
>Qiu Xiuping wrote:
>>
>> Hi,Brian and all
>>
>> Two attributes of context are the priority and the emergency
>> Annex A describes the priority , but not the emergency.
>>
>> I wander what's the difference between the priority and Emergency.
>> And how to use them.
>>
>> Regards,
>> Xiuping Qiu
>> _______________________________________________
>>
>> Xiuping Qiu
>> Huawei Technologies Co., Ltd.
>> Mail to   qiuxiuping@sz.huawei.com.cn
>> Visit     http://www.huawei.com.cn
>> _______________________________________________


Regards,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   qiuxiuping@sz.huawei.com.cn
Visit     http://www.huawei.com.cn
_______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 09:04:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10089
	for ; Fri, 21 Jan 2000 09:04:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C8F6520@standards.nortelnetworks.com>; Fri, 21 Jan 2000 9:02:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1965 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 09:01:33 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.1B35A510@standards.nortelnetworks.com>; Fri, 21 Jan 2000 9:01:29
          -0500
Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id TAA31962; Fri, 21 Jan 2000
          19:26:48 +0530 (IST) (envelope-from hsanand@ficon-tech.com)
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3885AE0C.8A0302A4@ficon-tech.com> <38872987.C6B26B3F@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38886633.76E014E7@ficon-tech.com>
Date:         Fri, 21 Jan 2000 19:29:15 +0530
Reply-To: hsanand@ficon-tech.com
Sender: "Media Gateway Control (megaco)"
              
From: Harpreet Singh Anand 
Organization: Ficon Technology
Subject:      Re: Comments on v13 draft
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

John,


> I realize that I'm not Brian, but would like to comment on some of the
> points you raise nevertheless :)

Thanks for the reply.

>
> > 3. For audit value what is the difference between ObservedEventsDescriptor and
> > EventBuffer Descriptor. Only
> > EventBuffer Descriptor should be sufficient. Similarly for Audit Capabilities,
> > what would be returned in
> > EventBufferDescriptor ?
>
> Yes, there's something strange here.  How about this:
>
> - When EventBuffer descriptor is included in a request from MGC to MG,
> it indicates which events the MG must detect when no Events descriptor
> is active.
> - When an MG is audited by means of AuditValue, it returns events that
> are in the buffer in ObservedEvents descriptor
> - When an MG is audited by means of AuditValue, it returns the events
> that it will detect when no Events descriptor is active in EventBuffer
> descriptor.

I believe that in the last bullet you meant AuditCapability. But even then what will
happen if the AuidtCpabaility is sent when the Event descriptor is active - will the
events be sent in ObservedEvents Descriptor ?

> > 4. Section 7.3: Error Codes 466, 467: There is no need of sending these error
> > descriptors as these are supposed to be
> > handled by the ALF and is not an error condition.
>
> Does the ALF protect against the megaco application sending duplicate
> requests?

Yes, it does.

> > 5. Sec 7.1.12:  Audit Descriptor: Media Descriptor has been removed from the
> > list of items that can be send in Audit
> > Descriptor. However, it has not been removed from the ABNF rules
> > (auditReturnParameter and auditItem).
>
> Actually, it seems that Media descriptor wasn't in the table in v12
> either.  I added it.

So what's the final position - is it in or out ?


Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:hsanand@ficon-tech.com
Web    :  http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 09:53:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11086
	for ; Fri, 21 Jan 2000 09:53:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.179E7060@standards.nortelnetworks.com>; Fri, 21 Jan 2000 9:51:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2016 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 09:50:00 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.E0E9C510@standards.nortelnetworks.com>; Fri, 21 Jan 2000 9:49:58
          -0500
Received: from ficon-tech.com (vikasb.india.ficon-tech.com [172.25.1.109]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id UAA33578 for
          ; Fri, 21 Jan 2000 20:15:50
          +0530 (IST) (envelope-from skgupta@ficon-tech.com)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3888737E.D8D3ED84@ficon-tech.com>
Date:         Fri, 21 Jan 2000 20:25:58 +0530
Reply-To: "Sanjay Kr. Gupta" 
Sender: "Media Gateway Control (megaco)"
              
From: "Sanjay Kr. Gupta" 
Organization: Ficon Technology
Subject:      question on hex digits...
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello Brian, Abdallah,

    In the latest draft v13 the ABNF has been modified for hex digits to
preceed with 0x but not for all cases.
In the production
    hex4 = 1*4 HEXDIG
this change has not been incorporated. This production should be changed
to
    hex4 = "0x" 1*4 HEXDIG


Regards,
Sanjay Kr. Gupta
Ficon Technology
e-mail : mailto:skgupta@ficon-tech.com
web: http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 11:06:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12581
	for ; Fri, 21 Jan 2000 11:06:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.548277B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 11:04:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2153 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 11:02:49 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A7EA2940@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          10:52:48 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          QAA25160; Fri, 21 Jan 2000 16:53:56 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id QAA16807;
          Fri, 21 Jan 2000 16:53:56 +0100
Received: from ericsson.com (kipe141.eraj.ericsson.se [147.214.68.141]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          QAA29999; Fri, 21 Jan 2000 16:53:55 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <20000121135832.AAA25630@q17326>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38888114.E4311D29@ericsson.com>
Date:         Fri, 21 Jan 2000 16:53:56 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: What's the difference between the Priority and Emergency
X-To:         Qiu Xiuping 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Xiuping,

This is really dependant on the application running. The MG should
handle resource differently for emergency and priority but we can't say
how in H248 because its a service interaction and implementation issue.

Cheers, Christian

Qiu Xiuping wrote:
>
> Hi, Christian Groves?!
>
> Yeah, You are right. :-)
>
> But I still want to know if there is a context with priority = 15 or other level
> and a context with emergency =1 , then which context should be served first.
>
> At 00-1-21 14:31:00 you wrote?o
> >Hello Xiuping,
> >
> >Priority and emergency are two different services. Emergency could be
> >used when you want to have an emergency (ie.911) call. The MG could
> >decide to release resources to let this through.
> >
> >Priority is used like in the MLPP service in ISUP.
> >
> >Annex A contains both the priority and emergency. Please see below.
> >
> >ContextRequest ::= SEQUENCE
> >{
> >       priority        INTEGER(0..15) OPTIONAL,
> >       emergency       BOOLEAN OPTIONAL,
> >       topologyReq     SEQUENCE OF TopologyRequest OPTIONAL,
> >       ...
> >}
> >
> >Cheers, Christian
> >
> >Qiu Xiuping wrote:
> >>
> >> Hi,Brian and all
> >>
> >> Two attributes of context are the priority and the emergency
> >> Annex A describes the priority , but not the emergency.
> >>
> >> I wander what's the difference between the priority and Emergency.
> >> And how to use them.
> >>
> >> Regards,
> >> Xiuping Qiu
> >> _______________________________________________
> >>
> >> Xiuping Qiu
> >> Huawei Technologies Co., Ltd.
> >> Mail to   qiuxiuping@sz.huawei.com.cn
> >> Visit     http://www.huawei.com.cn
> >> _______________________________________________
>
> Regards,
> Xiuping Qiu
> _______________________________________________
>
> Xiuping Qiu
> Huawei Technologies Co., Ltd.
> Mail to   qiuxiuping@sz.huawei.com.cn
> Visit     http://www.huawei.com.cn
> _______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:01:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13784
	for ; Fri, 21 Jan 2000 12:01:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E4F64770@standards.nortelnetworks.com>; Fri, 21 Jan 2000 11:58:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2240 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 11:57:14 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.422EF150@standards.nortelnetworks.com>; Fri, 21 Jan 2000 11:47:13
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA16712; Fri, 21 Jan
          2000 11:48:34 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA26862; Fri, 21 Jan
          2000 11:48:37 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 11:45:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2087FA@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 11:48:33 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
X-To:         Qiu Xiuping 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Qiu Xiuping [mailto:qiuxiuping@sz.huawei.com.cn]
> Sent: Thursday, January 20, 2000 6:31 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject:
>
I have had some connectivity problems while traveling, and am way
behind on comments to V13.  On the other hand, today is the day
we wish to settle the text, if at all possible.

I know there are other messages on this thread already, but this
is my opinion



>
> Hi, All .
>
> While reading MEGACO/H.248  version 13,  I meet some questions.
>
> 1. In  6.2 " Terminations may be created which represent
> multiplexed bearers, "
>
> I don't understand what multiplexed bearer mean.. Will you
> please give a detailed example?
This was answered correctly, AAL1/2, or there are several proposals
to create a multiplexed RTP.  More than one "call" on a single
bearer "connection"

> 2. In  6.2.4   property may be declared as "Global"
>
> I don't know how to decalre a property as " Global", I read
> everything but find nothing more
> about it. And  it is the same with the " "Properties may be
> read-only or read/write "" ,
> there is  no  place to  declare a property to be  read-only.
You literally say "Global" and/or "read-only",.... in the
package definition document.  It goes in the "characteristics"
line.  The text in section 12.1.3 needs to be modified to mention
this.

>
>
> 3. In 7.1.8 Local and Remote Descriptors
>
>  Local refers to the media received by the MG and Remote
> refers to the media sent by the MG.
>
> I think this sentence is misfortune to be typo error. :-)
There is some confusion here.  I think we need to align it with MGCP,
as there is no other reason to choose, and we unnecessarily
confuse people if they are different.  In MGCP, local specifies
what you receive.


>
> 4 In 7.1.9 Events Descriptor
>
> The MG shall send a Notify command to the MGC when it detects
> an event in the Events Descriptor.   "
>
> If so, what is the use of  eventbuffer ?
I think this was answered.  EventsDescriptor specifies what
to look for, ObservedEvents Descriptor tells you what has
been detected.  EventBuffer specifies what to look for after
you have found an event in EventsDescriptor but before the
MGC can come back with a new EventsDescriptor.

>
> 5 In 7.2.5 AuditValue ".
>
> If the TerminationId is wildcarded, only one command return
> is generated, with the contents containing the union
> of the values of all Terminations matching the wildcard.
> This convention may reduce the volume of data required
> to audit a group of Terminations "
>
> Will you please give me a example for union of the values of
> all Terminations matching the wildcard?
Also answered reasonably.  Suppose I had 3 terminations A1, A2
and A3, and let's just say there was a property pf/c which
could have values 0-25.  Suppose A1's pf/c was currently 13,
and A2 as well as A3 currently have pf/c set to 0.  If you did
Context=*{W-AuditValue=A*{Audit{TerminationState}}}
your reply might look like
Context=*{W-AuditValue=A*{TerminationsState{...,pf/c={0,13}...

>
> 6. In 7.2.8 ServiceChange
>
> Restart - indicates that service will be restored on the
> specified Terminations after expiration of the
> ServiceChangeDelayThe MG should set serviceState to
> "inService" upon expiry of ServiceChangeDelay
>
> How to deal with the bad terminations ? They can not be in "
> inService "" of course.
They don't get restarted!  Maybe I misunderstand the question.

>
> 7 In 8.2.2 TransactionReply
>
> " If the end of a command cannot be reliably determined it
> will return 442 Syntax Error in Transaction as the reply to
> the last action it can parse."
>
> It seems that "442 Syntax Error in Transaction" should be
> corrected  to be " 442 Syntax Error in Command "  :-)
>
> 8 In 8.2.3 TransactionPending
>
> If a duplicate request is received when pending, the
> responder may send a duplicate pending immediately,
> or continue waiting for its timer to trigger another
> Transaction Pending.
>
> My question is how to determine to choose which  method?
It doesn't matter.  It is not necessary to send it as the
way the timers work, you will always get a response (either
the reply or another pending) from the original request
before you could get one from the duplicate.  It doesn't hurt
to get extra ones.  Your choice.

Brian

------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com


>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:10:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13928
	for ; Fri, 21 Jan 2000 12:10:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2898C600@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:07:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2243 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:06:09 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8145F450@standards.nortelnetworks.com>; Fri, 21 Jan 2000 11:56:09
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA17860; Fri, 21 Jan
          2000 11:57:36 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA29195; Fri, 21 Jan
          2000 11:57:29 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 11:54:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6430.3212659C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2087FC@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 11:57:26 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Questions on MEGACO
X-To:         Shalini Philip 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6430.3212659C
Content-Type: text/plain;
        charset="iso-8859-1"

I'm sorry if I missed sending a reply to this

-----Original Message-----
From: Shalini Philip [mailto:sphilip@ficon-tech.com]
Sent: Thursday, January 20, 2000 7:00 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Questions on MEGACO


Hello Brian,

1. This is regarding mandatory parameters and was raised recently on the
mailing list, but to which there was no reply. So I am resending the same.
In section 7.1.1
"Unspecified mandatory parameters (i.e. mandatory parameters not specified
in a descriptor)
result in the command responder retaining the previous value for that
parameter"
Does that mean that none of the parameters in a descriptor are actually
"mandatory" in the real sense of the term ?

Yeah, maybe it's a poor choice of words.  The idea is that some things
really are optional. The ones that aren't really optional have to have a
value at all times.  They have a default, you can change it in null.  When
you Add it to a context, you usually specify the value if the default is not
what you want.  Leaving it out of the descriptor causes it to keep
the current value.



2. Consider the situation of failure of an MGC and MGC handing off MG to a
different MGC.
Section 11.5 says that
"When the MGC initiates a HandOff, the handover should be transparent to the
operations on the Media Gateway.  Transactions can be executed in any order,
and could be in progress when the ServiceChange is executed.  Accordingly,
commands in progress continue, transaction replies are sent to the new MGC,
and the MG should expect outstanding transaction replies from the new MGC.
Since all connections should stay up."


However there is some text in the ALF Section Annexe D, in D.1.4, which also
talks about handoff and which says,
"In order to account for the possibility of an undetected or in-progress
"failover", we modify the classic algorithm so that if the Media Gateway
receives a valid ServiceChange message announcing a failover, it will start
transmitting outstanding commands to that new MGC.  Responses to commands
are still transmitted to the source address of the command."


Can you please clarify what action actually needs to be taken, the one
specified in section 11.5, where the transaction replies are sent to the new
MGC
    Or
the one specified in D.1.4., where the command responses are sent to the
source address of the command ?

Yes, we must fix this.  I think you have to send the replies to the old one.
Any other opinions?


------_=_NextPart_001_01BF6430.3212659C
Content-Type: text/html;
        charset="iso-8859-1"









        I'm sorry if
I missed sending a reply to this
        

        
  
        -----Original Message-----
        From: Shalini Philip
  [mailto:sphilip@ficon-tech.com]
        Sent: Thursday, January 20, 2000
  7:00 AM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Questions on MEGACO

        
  
        Hello Brian, 
          
        1. This is regarding mandatory
  parameters and was raised recently on the mailing list, but to which there was
  no reply. So I am resending the same. 
        In section 7.1.1 
        "Unspecified
  mandatory parameters (i.e. mandatory parameters not specified in a descriptor)
  
        result in the command responder retaining the previous value for that
  parameter" 
        Does that mean that none of the parameters in a descriptor are
  actually "mandatory" in the real sense of the term ?  
        
  
         
        
  
        Yeah, maybe
  it's a poor choice of words.  The idea is that some things really are
  optional. The ones that aren't really optional have to have a value
  at all times.  They have a default, you can change it in
  null.  When you Add it to a context, you usually specify the value
  if
  the default is not what you want.  Leaving it out of the
  descriptor causes it to keep
        
  
        the current
  value.
        
  
         
        
  
         
        
  
        2. Consider the situation of failure of an MGC and MGC handing off MG to a
  different MGC. 
        Section 11.5 says that 
        "When the MGC initiates a
  HandOff, the handover should be transparent to the operations on the Media
  Gateway.  Transactions can be executed in any order, and could be in
  progress when the ServiceChange is executed.  Accordingly, commands in
  progress continue, transaction replies are sent to the new MGC, and the
  MG should expect outstanding transaction replies from the new MGC.  Since
  all connections should stay up."
  
        However there is some text in the ALF Section Annexe D, in D.1.4, which
  also talks about handoff and which says, 
        "In order to account for the
  possibility of an undetected or in-progress "failover", we modify the classic
  algorithm so that if the Media Gateway receives a valid ServiceChange message
  announcing a failover, it will start transmitting outstanding commands to that
  new MGC.  Responses to commands are still transmitted to the source
  address of the command."
  
        Can you please clarify what action actually needs to be taken, the one
  specified in section 11.5, where the transaction replies are sent to the new
  MGC 
            Or 
        the one specified in D.1.4., where the
  command responses are sent to the source address of the command ?  
        
  
        Yes, we must
  fix this.  I think you have to send the replies to the old one.  Any
  other opinions?
        

------_=_NextPart_001_01BF6430.3212659C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:10:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13932
	for ; Fri, 21 Jan 2000 12:10:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.292A3090@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:08:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2249 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:07:20 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AB60EA60@standards.nortelnetworks.com>; Fri, 21 Jan 2000 11:57:19
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA18053; Fri, 21 Jan
          2000 11:58:46 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA29624; Fri, 21 Jan
          2000 11:58:49 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 11:55:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2087FD@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 11:58:46 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Wildcard Response
X-To:         Qiu Xiuping 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA13932

I think I dealt with this in a prior reply.  If it's still not
clear, ask again.

Brian

> -----Original Message-----
> From: Qiu Xiuping [mailto:qiuxiuping@sz.huawei.com.cn]
> Sent: Thursday, January 20, 2000 9:14 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Wildcard Response
> 
> 
> Hi, Harpreet Singh Anand£¡
> 
> My comment is marked with Qiu
> 
> At 00-1-20 18:01:00 you wrote£º
> The only useful wildcard operation for AuditValue seems to be 
> a wildcard audit of the packages. MGC can send a wild card 
> AuditValue command having TerminationId as * and 
> AuditDescriptor having only one
> audit item, viz Package Descriptor. In the reply, MG would 
> send a send a single reply with termination id as * and a 
> single package descriptor having the union of all the 
> packages that are supported on all
> the terminations in the MG.
> 
> **************************************************************
> ***************************************
> 
> Qiu :
> But wildcard operation is not not only useful for AuditValue really.
> It is useful for other commands also.  Let's think of its 
> common usage .
> 
> I think the wildcard operation as below:
> 
> 1. sends a command with all wildcard TerminationID
> 
> 2. response for each wildcarded TerminationID
> 
> TransactionReply {
>               TransactionID ,
>               ActionReply {
>                       ContextID ,
>                       CommandReply {
>                               TerminationID,............
>                               TerminationID, ...........
>                               TerminationID, ........... ( 
> the following parameters may be different)
>                                       }
> In this kind of  reply , TerminationID standars for 
> wildcarded Termination case,
> The following parameters may be different.
> 
> 
> 
> 3. Union Reply
> 
> TransactionReply {
>               TransactionID,
>               ActionReply {
>                       ContextID ,
>                       CommandReply {
>                                * , .................( the 
> following parameters should be the same)
>                                       }
> In this kind of reply , the TerminationID is * , standards 
> for all TerminationID,
> but the result must be the same.
> 
> 
> My question is, if the following parameters are different. 
> how can the reply be united ?
> 
> 
> Regards,
> Xiuping Qiu
> _______________________________________________
> 
> Xiuping Qiu
> Huawei Technologies Co., Ltd.
> Mail to   qiuxiuping@sz.huawei.com.cn
> Visit     http://www.huawei.com.cn
> _______________________________________________
> 


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:22:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14297
	for ; Fri, 21 Jan 2000 12:22:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DA90A8E0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:20:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2287 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:18:32 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3C2050D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:08:32
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA19542; Fri, 21 Jan
          2000 12:09:59 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA02557; Fri, 21 Jan
          2000 12:10:01 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 12:07:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF2087FE@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 12:09:50 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Comments on v13 draft
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have had some connectivity problems while traveling, and am way
behind on comments to V13.  On the other hand, today is the day
we wish to settle the text, if at all possible.

My comments with [br] below

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Thursday, January 20, 2000 10:28 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Comments on v13 draft
>
>
> Harpreet,
>
> I realize that I'm not Brian, but would like to comment on some of the
> points you raise nevertheless :)
>
> Cheers,
>
> John
>
> Harpreet Singh Anand wrote:
> >
> > Hello Brian,
> >
> > Some editorial comments / issues on v13 draft:
> >
> > 1. In the v13 draft, there is no mention of audit of
> ephemeral terminations
> > (Washington Issue #1). Has this idea been dropped ?
>
> I remember the lively discussions in Washington, but only part of the
> proposed resolution (a ROOT property).  Tom and/or Brian may
> be able to
> take this one.
[br] oh boy, I forgot to put the terminationId name pattern in
the root package.  Sorry, I'll get that done today.
That allows you do audit ephemerals if the name pattern shows up.
Of course, once instantiated, you can audit an ephemeral now, the
question was whether you could do so before you instantiated one.

> > 2. SDP related:
> >
> >  - Details on the changes required in the SDP grammer
> (symbol to be used for
> > wildcard etc.) are missing.
> >
> >  - The specification should give details of the SDP fields
> (example network
> > type, media type, transport type, any
> > additional attributes) that would be used in MEGACOP.
> Similar information has
> > been provided in MGCP and is useful
> > for achieving interoperability. Similarly ATM bearer
> description in SDP should
> > also be defined (or a pointer given to
> > the relevant document).
>
> The usual mode of operation is that Brian handles the text/SDP related
> stuff and I focus on the binary.  So, again, I call upon Brian to take
> up this question.
[br] Yep, more stuff for me to do today


> > 3. For audit value what is the difference between
> ObservedEventsDescriptor and
> > EventBuffer Descriptor. Only
> > EventBuffer Descriptor should be sufficient. Similarly for
> Audit Capabilities,
> > what would be returned in
> > EventBufferDescriptor ?
>
> Yes, there's something strange here.  How about this:
>
> - When EventBuffer descriptor is included in a request from MGC to MG,
> it indicates which events the MG must detect when no Events descriptor
> is active.
> - When an MG is audited by means of AuditValue, it returns events that
> are in the buffer in ObservedEvents descriptor
> - When an MG is audited by means of AuditValue, it returns the events
> that it will detect when no Events descriptor is active in EventBuffer
> descriptor.
[br] That is correct.  You also get ObservedEvents in the Notify.
Notice that EventsDescriptor and EventBufferDescriptor both
are sent by the MGC and not changed by the MG (when you audit
them, they come back the same as when the MGC sent them).
ObservedEvents tells you what has been detected.  After you send
an Events Descriptor, the items you would see in it would be
those in that Events Descriptor.  Once one of them is detected,
those you would see would be those in the EventBuffer descriptor.
Of course there can be overlap of events in both descriptors.



>
> > 4. Section 7.3: Error Codes 466, 467: There is no need of
> sending these error
> > descriptors as these are supposed to be
> > handled by the ALF and is not an error condition.
>
> Does the ALF protect against the megaco application sending duplicate
> requests?
[br]It should ignore duplicate requests, so is not an error

> > 5. Sec 7.1.12:  Audit Descriptor: Media Descriptor has been
> removed from the
> > list of items that can be send in Audit
> > Descriptor. However, it has not been removed from the ABNF rules
> > (auditReturnParameter and auditItem).
>
> Actually, it seems that Media descriptor wasn't in the table in v12
> either.  I added it.
[br] someone tell me why you can't audit Media?  You have to be
able to do that, right?   The real thing is that you can't audit
a single stream.  You could audit Local, but that would always get
you Stream=1.

> > 6. Sec 7.1.12: Audit Descriptor: Event Buffer descriptor
> should be added to the
> > table.
>
> Yes.
>
> > 7. Sec 7.1.18: Second paragraph: "The Topology Descriptor
> precedes any commands
> > within an action. ". However
> > according to the ABNF rule, actionRequest, context
> properties can come only
> > before the first command.
>
> Uncareful use of language on my part.  Change to "The Topology
> Descriptor precedes the commands of an action." ok?
>
> > 8. Sec 7.2.5: Audit Value:  Second paragraph: "If the
> TerminationId is
> > wildcarded, only one command return is
> > generated, with the contents containing the union of the
> values of all
> > Terminations matching the wildcard.". This can be
> > rephrased as " If the command is wildcarded, ....". Same
> comment for Sec 7.2.6
>
> I think you're right.  How about "If a wildcarded response is
> requested,
> [...]"?
>
> > 9. Section 7.2.8:  " 6. Failover - sent from MG to MGC to
> indicate the primary
> > MG is out of service and a secondary
> > MG is taking over." Failover is also used by MG when the
> MGC initiates
> > switchover, in this Failover indicates that the
> > active MGC is going out of service and it is redirecting MG
> to connect to a
> > separate MGC.
>
> Absolutely right.
>
> > 10. Section 7.2.8: Summary of use of properties in the
> Service Descriptor:
> > "Profile required if terminationID is not
> > ROOT, optional otherwise". Shouldn't this be the other way
> round that is
> > "Profile required if terminationID is
> > ROOT, optional otherwise"
>
> Yes.
>
> > 11. Section 8.2.2: "If a command is marked as optional, the
> MG has the choice of
> > executing it or not, and if it does
> > execute it, it returns the Response, or Error. " This line
> should be removed.
>
> Ok.
>
> > ABNF related:
> >
> > 1. Sec 7.1.5; This section mentions that the properties can
> take a value CHOOSE.
> > But the ABNF rule parmValue does
> > not allow choose.
>
> You're right.  I'll leave it to the ABNF experts to deal with
> this.  The
> ASN.1 allows CHOOSE value to be used.
>
> > 2. Sec 7.1.7: LocalControl Descriptor: reserve has been
> defined as a parameter
> > to LocalControl Descriptor but is is
> > missing in the ABNF.
>
> You're right.  I'll leave it to the ABNF experts.  ASN.1 is fixed.
>
> > 3.  Sec 7.1.14: The new text in DigitMap Descriptor section
> explains that the
> > possible letters in the digit map string can
> > be from A to k but the same has not been reflected in the ABNF.
>
> You're right.  I'll leave it to the ABNF experts.
>
> > Regards,
> > Harpreet
> >
> > _________________________________
> > Harpreet Singh Anand
> > Ficon Technology
> > E-mail :  mailto:hsanand@ficon-tech.com
> > Web    :  http://www.ficon-tech.com
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:brosen@eng.fore.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:26:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14331
	for ; Fri, 21 Jan 2000 12:26:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6AD619D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:24:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2336 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:22:30 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.C6914B70@standards.nortelnetworks.com>;
          Fri, 21 Jan 2000 12:12:24 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id LAA01985
          for ; Fri, 21 Jan 2000 11:13:14
          -0600 (CST)
Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma001742; Fri, 21 Jan 00 11:12:07 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id LAA29907 for
          ; Fri, 21 Jan 2000 11:12:06
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC56D for
          ; Fri, 21 Jan 2000 11:12:05 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id LAA19388 for ; Fri, 21
          Jan 2000 11:11:34 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA04232
          for ; Fri, 21 Jan 2000 11:11:33
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------C26B9F8F2F968742EF7AE455"
Message-ID:  <38889345.53C13B34@usa.alcatel.com>
Date:         Fri, 21 Jan 2000 11:11:33 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      suspicion & disconnection threshold
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------C26B9F8F2F968742EF7AE455
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

Megaco v13, Section D.1.4
"We should note that the "suspicion threshold", which we will call
"Max1", is normally
lower than the "disconection threashold", which should be set to a
larger value."

The paragraph containing these 2 sentences is incomplete.
The paragraph can be traced to MGCP RFC 270 section 4.2 which tries to
specify what MG should do if
"suspicion threshold" is exceeded.

Quote from MGCP  (Max2 is equivalent to disconnection threshold above):
"we request that if the number of repetitions for this Call Agent is
larger than "Max1", that
the gateway actively queries the name server in order to detect the
possible change of the
call agent interfaces."
"The gateway may have learned several IP addresses for the call agent.
If the number of
repetitions is larger than "Max1" and lower than "Max2", and there are
more interfaces that
have not been tried, then the gateway should direct the retransmissions
to alternate
address."
"If there are no more interfaces to try, and the number of repetitions
is Max2, then the gateway
contacts the DNS one more time to see if any other interface should have
become available.
If not, the gateway is disconnected."

Does Megaco want to implement "suspicion" and "disconnection" threshold
as specified in MGCP?
If not, it seems like only a "disconnection threshold" is needed.
If yes, more text is needed in D.1.4


Thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------C26B9F8F2F968742EF7AE455
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi

        Megaco v13, Section D.1.4

        "We should note that the "suspicion threshold", which we will call
"Max1", is normally

        lower than the "disconection threashold", which should be set to a
larger value."

        The paragraph containing these 2 sentences is incomplete.

        The paragraph can be traced to MGCP RFC 270 section 4.2 which tries
to specify what MG should do if

        "suspicion threshold" is exceeded.

        Quote from MGCP  (Max2 is equivalent to disconnection threshold
above):

        "we request that if the number of repetitions for this Call Agent is
larger than "Max1", that

        the gateway actively queries the name server in order to detect the
possible change of the

        call agent interfaces."

        "The gateway may have learned several IP addresses for the call agent. 
If the number of

        repetitions is larger than "Max1" and lower than "Max2", and there
are more interfaces that

        have not been tried, then the gateway should direct the retransmissions
to alternate

        address."

        "If there are no more interfaces to try, and the number of repetitions
is Max2, then the gateway

        contacts the DNS one more time to see if any other interface should
have become available.

        If not, the gateway is disconnected."

        Does Megaco want to implement "suspicion" and "disconnection" threshold
as specified in MGCP?

        If not, it seems like only a "disconnection threshold" is needed.

        If yes, more text is needed in D.1.4

         

        Thanks

        Chuong

        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------C26B9F8F2F968742EF7AE455--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 12:54:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14699
	for ; Fri, 21 Jan 2000 12:54:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.567C2700@standards.nortelnetworks.com>; Fri, 21 Jan 2000 12:52:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2425 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 12:50:31 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.B17B0D80@standards.nortelnetworks.com>;
          Fri, 21 Jan 2000 12:40:26 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id LAA05851
          for ; Fri, 21 Jan 2000 11:41:42
          -0600 (CST)
Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma005812; Fri, 21 Jan 00 11:41:09 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id LAA15396 for
          ; Fri, 21 Jan 2000 11:41:05
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA1688 for
          ; Fri, 21 Jan 2000 11:41:03 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id LAA25327 for ; Fri, 21
          Jan 2000 11:40:59 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA04264
          for ; Fri, 21 Jan 2000 11:40:59
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF2087FE@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------06634A48AEA199925F7187D6"
Message-ID:  <38889A2B.7728A38@usa.alcatel.com>
Date:         Fri, 21 Jan 2000 11:40:59 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Comments on v13 draft
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------06634A48AEA199925F7187D6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > > 2. SDP related:
> > >
> > >  - Details on the changes required in the SDP grammer
> > (symbol to be used for
> > > wildcard etc.) are missing.
> > >
> > >  - The specification should give details of the SDP fields
> > (example network
> > > type, media type, transport type, any
> > > additional attributes) that would be used in MEGACOP.
> > Similar information has
> > > been provided in MGCP and is useful
> > > for achieving interoperability. Similarly ATM bearer
> > description in SDP should
> > > also be defined (or a pointer given to
> > > the relevant document).
> >
> > The usual mode of operation is that Brian handles the text/SDP related
> > stuff and I focus on the binary.  So, again, I call upon Brian to take
> > up this question.
> [br] Yep, more stuff for me to do today
>

[cnn] Since you are going to clarify SDP.  Can I do the following?
            Remote{SDP{}}
Will I get a syntax error?  I am trying to tell MG to clear out its Remote
SDP info.
I want to keep the stream but I do not know the new Remote SDP info yet.


>
> > > 5. Sec 7.1.12:  Audit Descriptor: Media Descriptor has been
> > removed from the
> > > list of items that can be send in Audit
> > > Descriptor. However, it has not been removed from the ABNF rules
> > > (auditReturnParameter and auditItem).
> >
> > Actually, it seems that Media descriptor wasn't in the table in v12
> > either.  I added it.
> [br] someone tell me why you can't audit Media?  You have to be
> able to do that, right?   The real thing is that you can't audit
> a single stream.  You could audit Local, but that would always get
> you Stream=1.
>
>

Yes, I want to be able to audit Media for all streams down to each stream
Local and Remote Descriptors.
This will allow MGC to rebuild any database that it needs for each context
after MGC somehow
lost these info.
Are you saying that one can audit Media for a streams but one can't specify
a specific stream to
audit?

thanks
Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------06634A48AEA199925F7187D6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit





        > > 2. SDP related:

        > >

        > >  - Details on the changes required in the SDP grammer

        > (symbol to be used for

        > > wildcard etc.) are missing.

        > >

        > >  - The specification should give details of the SDP fields

        > (example network

        > > type, media type, transport type, any

        > > additional attributes) that would be used in MEGACOP.

        > Similar information has

        > > been provided in MGCP and is useful

        > > for achieving interoperability. Similarly ATM bearer

        > description in SDP should

        > > also be defined (or a pointer given to

        > > the relevant document).

        >

        > The usual mode of operation is that Brian handles the text/SDP related

        > stuff and I focus on the binary.  So, again, I call upon Brian
to take

        > up this question.

        [br] Yep, more stuff for me to do today

         
        
[cnn] Since you are going to clarify SDP.  Can I do the following?

                   
Remote{SDP{}}

        Will I get a syntax error?  I am trying to tell MG to clear out
its Remote SDP info.

        I want to keep the stream but I do not know the new Remote SDP
info yet.

         

         

        > > 5. Sec 7.1.12:  Audit Descriptor: Media Descriptor has been

        > removed from the

        > > list of items that can be send in Audit

        > > Descriptor. However, it has not been removed from the ABNF rules

        > > (auditReturnParameter and auditItem).

        >

        > Actually, it seems that Media descriptor wasn't in the table in v12

        > either.  I added it.

        [br] someone tell me why you can't audit Media?  You have to be

        able to do that, right?   The real thing is that you can't
audit

        a single stream.  You could audit Local, but that would always
get

        you Stream=1.

         

         
        
Yes, I want to be able to audit Media for all streams down to each stream
Local and Remote Descriptors.

        This will allow MGC to rebuild any database that it needs for
each context after MGC somehow

        lost these info.

        Are you saying that one can audit Media for a streams but one can't
specify a specific stream to

        audit?

        thanks

        Chuong

        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------06634A48AEA199925F7187D6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 13:44:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15467
	for ; Fri, 21 Jan 2000 13:44:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.564B4ED0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 13:42:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2479 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 13:41:52 -0500
Received: from alpha.telecom-co.net (200.21.27.100) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DEBD08F0@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          13:31:49 -0500
Received: from lquiroga.alpha.telecom-co.net (itec.telecom-co.net
          [200.21.27.13]) by alpha.telecom-co.net with SMTP (Microsoft Exchange
          Internet Mail Service Version 5.5.1960.3) id D1B09WMA; Fri, 21 Jan
          2000 13:37:34 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0011_01BF6414.41FBAE80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID:  <001401bf643e$2cb0d6c0$0d1b15c8@lquiroga.alpha.telecom-co.net>
Date:         Fri, 21 Jan 2000 13:34:35 -0500
Reply-To: Luis Carlos Quiroga H 
Sender: "Media Gateway Control (megaco)"
              
From: Luis Carlos Quiroga H 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0011_01BF6414.41FBAE80
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



------=_NextPart_000_0011_01BF6414.41FBAE80
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










         
        

------=_NextPart_000_0011_01BF6414.41FBAE80--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 14:19:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15899
	for ; Fri, 21 Jan 2000 14:19:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C414120@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:17:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2521 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 14:16:12 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.ABEF6990@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:06:11
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA03198; Fri, 21 Jan
          2000 14:07:39 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA00079; Fri, 21 Jan
          2000 14:07:42 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 14:04:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6442.62597634"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208803@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 14:07:34 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: ServiceChange
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6442.62597634
Content-Type: text/plain;
        charset="iso-8859-1"



-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Thursday, January 20, 2000 2:25 PM
To: MEGACO@standards.nortelnetworks.com
Subject: ServiceChange


Brian
We have discussed ServiceChange methods before regarding registration.
But I do not see any new clarification in v13.
You have mention that the first message from MG to MGC should always be
ServiceChange w/Restart.  MGC will always have the option to deny
service to registering MG.

Section 11.5 Failure of MG
"The MG should send a ServiceChange message with a "Failover" method
and a "MGC directed change" reason to the designated MGC.  If it
fails to get a reply, or fails to see an Audit command consequently,
it should behave as if it's MGC failed, and start contacting
secondary MGCs."
Why can't MG send ServiceChange w/Restart here since it is trying to
register with the new MGC?  The reason can be "Failover: MGC
directed change"?
I feel we should have just one way to do this.  There is quite a difference
between an MG first
starting, when it has no state to speak of, or is recovering from failure of
the MGC, where
it has lots of state.  That is why I think the method is "failover".
Regardless, the reason has
to make clear that the MG had been running, and is now being forced to
change MGCs.
Calls may be up, in particular.


In hindsight, there is no reason to have "method" and "reason".  One
parameter should
be sufficient..
Regardless of the ServiceChange method issue, does new MGC still has the
option to deny service to this requesting MG even though this MG
was directed by the failing MGC?  If the answer is yes, what should
the MG do - contact secondary MGC?
Yes

Last quoted sentence, does the MG use Restart or Failure to contact
secondary MGCs?
Failure


There are really 2 methods for registration, Restart or Failover
as being the first message from MG to MGC.  Section 7.2.8 implies
only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.

Section 7.2.8 ServiceChange
"6. Failover - send from MG to MGC to indicate the primary MG is out
service and a secondary MG is taking over."
This matches section 11.4 but in section 11.5, this method is also
used by MG to register with Primary or Secondary MGC.

Does the text need to be cleaned or more clarification?
We should look at that.



Thanks
Chuong



--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****



------_=_NextPart_001_01BF6442.62597634
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









         
        

  
        -----Original Message-----
        From: Chuong Nguyen=20
  [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
        Sent: Thursday, =
January 20,=20
  2000 2:25 PM
        To:=20
  MEGACO@standards.nortelnetworks.com
        Subject:=20
  ServiceChange

        Brian
        We have =
discussed ServiceChange methods before regarding =
registration.
        But I do not see any new clarification in =
v13.
        You have mention that the first message from MG to MGC =
should always be
        ServiceChange w/Restart.  MGC will =
always have the option to deny
        service to registering =
MG.
        Section 11.5 Failure of MG
        "The MG =
should send a ServiceChange message with a "Failover" =
method
        and a "MGC directed change" reason to the designated =
MGC.  If it
        fails to get a reply, or fails to see an =
Audit command consequently,
        it should behave as if it's MGC =
failed, and start contacting
        secondary MGCs."
        Why =
can't MG send ServiceChange w/Restart here since it is trying =
to
        register with the new MGC?  The reason can be =
"Failover: MGC
        directed change"? 
        I feel we =
should have just one way to do this.  There is quite a difference =
between an MG first
        starting, when it has =
no state to speak of, or is recovering from failure of the MGC, =
where
        it has lots of state.  That is why I =
think the method is "failover".  Regardless, the reason has
        to make =
clear that the MG had been running, and is now being forced to change =
MGCs.
        Calls may be up, in particular.

        In =
hindsight, there is no reason to have "method" and "reason".  One =
parameter should
        be =
sufficient.. 
        Regardless of the =
ServiceChange method issue, does new MGC still has the
        option =
to deny service to this requesting MG even though this MG
        was =
directed by the failing MGC?  If the answer is yes, what =
should
        the MG do - contact secondary MGC? 
        Yes
         
        Last quoted =
sentence, does the MG use Restart or Failure to =
contact
        secondary MGCs? 
        Failure
         
        The=
re are really 2 methods for registration, Restart or =
Failover
        as being the first message from MG to MGC.  =
Section 7.2.8 implies
        only one - Restart w/ROOT.  =
Section 11.5 implies Failover w/ROOT.
        Section =
7.2.8 ServiceChange
        "6. Failover - send from MG to MGC to =
indicate the primary MG is out
        service and a secondary MG is =
taking over."
        This matches section 11.4 but in section 11.5, =
this method is also
        used by MG to register with Primary or =
Secondary MGC.
        Does the text need to be cleaned or =
more clarification? 
        We should =
look at that.
         
         
        Tha=
nks
        Chuong
        -- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
         =20


------_=_NextPart_001_01BF6442.62597634--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 14:29:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16003
	for ; Fri, 21 Jan 2000 14:29:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A34EAC80@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:27:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2524 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 14:25:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.FC3EB030@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:15:35
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA04020; Fri, 21 Jan
          2000 14:17:00 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA02166; Fri, 21 Jan
          2000 14:17:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 14:14:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208804@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 14:16:55 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Choose option with wild card termination name
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Friday, January 21, 2000 4:01 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Choose option with wild card termination name
>
>
> Hi rayhan,list
>      The Termination ID description given in the section
> 6.2.2 say that the
> termination names can be specified which enables MG to choose
> a circuit
> within a trunk group. The text grammar defined  for
> TerminatinID is as follows:
>
> TerminationID = "ROOT" / pathNAME / "$" / "*"  and
> pathNAME = ["*"] NAME *("/" / "*"/ ALPHA / DIGIT /"_" )
>           ["@" pathDomainName ]
>
> the pathNAME rule doesn't have any "$" in it which enable MG
> to identify that
> its a wild card CHOOSE request. Can you clarify this query of mine.
We will have to fix this.  Anyone got a suggestion?  The big
problem is that you have to allow, but not require, hierarchical
names, so something like
pathName = ["*"] NAME *( "/" [NAME / "*" / "$") ["@" pathdomainName]
is not okay.  Just adding "$" after "/" / "*" / ALPHA is
not good, you only get to have one $.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 14:31:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16085
	for ; Fri, 21 Jan 2000 14:31:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBEC26C0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:29:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2540 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 14:29:03 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.77B5E580@standards.nortelnetworks.com>; Fri, 21 Jan 2000 14:19:03
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA04409; Fri, 21 Jan
          2000 14:20:21 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA02975; Fri, 21 Jan
          2000 14:20:24 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 14:17:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208806@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 14:20:19 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: question on hex digits...
X-To:         "Sanjay Kr. Gupta" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

> -----Original Message-----
> From: Sanjay Kr. Gupta [mailto:skgupta@ficon-tech.com]
> Sent: Friday, January 21, 2000 9:56 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: question on hex digits...
>
>
> Hello Brian, Abdallah,
>
>     In the latest draft v13 the ABNF has been modified for
> hex digits to
> preceed with 0x but not for all cases.
> In the production
>     hex4 = 1*4 HEXDIG
> this change has not been incorporated. This production should
> be changed
> to
>     hex4 = "0x" 1*4 HEXDIG
>
hex4 is only used in hexseq which is only used in an IPV6 address.
I believe we don't want to use 0x here.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 16:28:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17517
	for ; Fri, 21 Jan 2000 16:28:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.49BA7BC0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 16:26:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2655 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 16:25:01 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.AAF218A0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 16:15:00
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA16002 for
          ; Fri, 21 Jan 2000 16:16:28
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA01775 for
          ; Fri, 21 Jan 2000 16:16:31
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 16:13:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20880B@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 16:16:25 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Creating Streams & Moving Terminations when multiple streams are
              active
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

An issue has been raised on Streams.  7.1.7 includes text that
defines when streams are created, but there is no text describing
how streams are created.  Also, the text does not define what happens when
you move a termination where there are multiple streams, but
the streams in the old and new context are not congruent.

I propose the following text to be added to section 7.1.6

Streams are created by specifying a new StreamID on one of the terminations
in a Context. Streams are deleted by setting the Mode property in
LocalControl to "delete" on one of the terminations in a Context.

If a termination is moved from one context to another, any streams in the
new context that have the same Id, and the same media (as determined by
local and remote) on the moved termination remain active on that
termination.  Any streams that were active on a moved termination that were
not the same StreamId and the same media type in the new context are deleted
on that termination.  Any streams on a moved termination that are active in
the new context that did not have the same StreamId and media type as in the
old context are not active on the termination until an update of the Media
descriptor on the termination mentioning such stream is given (which may be
included in the Move command).

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 16:33:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17649
	for ; Fri, 21 Jan 2000 16:33:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE085200@standards.nortelnetworks.com>; Fri, 21 Jan 2000 16:31:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2672 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 16:30:56 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7CEBE930@standards.nortelnetworks.com>; Fri, 21 Jan 2000 16:20:53
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA16482; Fri, 21 Jan
          2000 16:22:10 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA03139; Fri, 21 Jan
          2000 16:22:13 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 16:19:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20880C@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 16:22:08 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Loop/Step
X-cc:         "csharp@cisco.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Apparently, someone thinks we still need loop/step.

I believe the current (V13) event model handles all necessary
interaction.  If you don't agree, please speak up and say
why!

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 16:58:44 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17847
	for ; Fri, 21 Jan 2000 16:58:43 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7DD0D8B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 16:56:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2731 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 16:54:44 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.CED19C60@standards.nortelnetworks.com>;
          Fri, 21 Jan 2000 16:44:39 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id PAA05399
          for ; Fri, 21 Jan 2000 15:45:57
          -0600 (CST)
Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma005361; Fri, 21 Jan 00 15:45:08 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id PAA16908 for
          ; Fri, 21 Jan 2000 15:45:06
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA664B for
          ; Fri, 21 Jan 2000 15:45:05 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id PAA09270 for ; Fri, 21
          Jan 2000 15:44:53 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA04526
          for ; Fri, 21 Jan 2000 15:44:53
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20880B@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------2C02E63401D850B194177275"
Message-ID:  <3888D355.E273B604@usa.alcatel.com>
Date:         Fri, 21 Jan 2000 15:44:53 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Creating Streams & Moving Terminations when multiple streams
              areactive
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------2C02E63401D850B194177275
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Brian

Can physical termination has multiple streams?  If yes, can you give me some
examples.

Thanks
Chuong


"Rosen, Brian" wrote:

> An issue has been raised on Streams.  7.1.7 includes text that
> defines when streams are created, but there is no text describing
> how streams are created.  Also, the text does not define what happens when
> you move a termination where there are multiple streams, but
> the streams in the old and new context are not congruent.
>
> I propose the following text to be added to section 7.1.6
>
> Streams are created by specifying a new StreamID on one of the terminations
> in a Context. Streams are deleted by setting the Mode property in
> LocalControl to "delete" on one of the terminations in a Context.
>
> If a termination is moved from one context to another, any streams in the
> new context that have the same Id, and the same media (as determined by
> local and remote) on the moved termination remain active on that
> termination.  Any streams that were active on a moved termination that were
> not the same StreamId and the same media type in the new context are deleted
> on that termination.  Any streams on a moved termination that are active in
> the new context that did not have the same StreamId and media type as in the
> old context are not active on the termination until an update of the Media
> descriptor on the termination mentioning such stream is given (which may be
> included in the Move command).
>
> Brian

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------2C02E63401D850B194177275
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Brian

        Can physical termination has multiple streams?  If yes, can you
give me some examples.

        Thanks

        Chuong

         

        "Rosen, Brian" wrote:

        An issue has been raised on Streams.  7.1.7
includes text that

        defines when streams are created, but there is no text describing

        how streams are created.  Also, the text does not define what
happens when

        you move a termination where there are multiple streams, but

        the streams in the old and new context are not congruent.

        I propose the following text to be added to section 7.1.6

        Streams are created by specifying a new StreamID on one of the terminations

        in a Context. Streams are deleted by setting the Mode property in

        LocalControl to "delete" on one of the terminations in a Context.

        If a termination is moved from one context to another, any streams in
the

        new context that have the same Id, and the same media (as determined
by

        local and remote) on the moved termination remain active on that

        termination.  Any streams that were active on a moved termination
that were

        not the same StreamId and the same media type in the new context are
deleted

        on that termination.  Any streams on a moved termination that
are active in

        the new context that did not have the same StreamId and media type
as in the

        old context are not active on the termination until an update of the
Media

        descriptor on the termination mentioning such stream is given (which
may be

        included in the Move command).

        Brian
        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------2C02E63401D850B194177275--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 17:26:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18084
	for ; Fri, 21 Jan 2000 17:26:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.69E97DD0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:24:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2769 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 17:22:55 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C1C29340@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:12:55
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA21382; Fri, 21 Jan
          2000 17:14:23 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA15423; Fri, 21 Jan
          2000 17:14:26 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 17:11:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF645C.78E1DC60"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208810@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 17:14:18 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Creating Streams & Moving Terminations when multiple streams
              areactive
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF645C.78E1DC60
Content-Type: text/plain;
        charset="iso-8859-1"

Sure, how about a stereo headphone pr a TV set with a cable TV connection




-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Friday, January 21, 2000 4:45 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Creating Streams & Moving Terminations when multiple streams
areactive


Brian

Can physical termination has multiple streams?  If yes, can you give me some
examples.


Thanks
Chuong



"Rosen, Brian" wrote:


An issue has been raised on Streams.  7.1.7 includes text that
defines when streams are created, but there is no text describing
how streams are created.  Also, the text does not define what happens when
you move a termination where there are multiple streams, but
the streams in the old and new context are not congruent.

I propose the following text to be added to section 7.1.6


Streams are created by specifying a new StreamID on one of the terminations
in a Context. Streams are deleted by setting the Mode property in
LocalControl to "delete" on one of the terminations in a Context.


If a termination is moved from one context to another, any streams in the
new context that have the same Id, and the same media (as determined by
local and remote) on the moved termination remain active on that
termination.  Any streams that were active on a moved termination that were
not the same StreamId and the same media type in the new context are deleted

on that termination.  Any streams on a moved termination that are active in
the new context that did not have the same StreamId and media type as in the

old context are not active on the termination until an update of the Media
descriptor on the termination mentioning such stream is given (which may be
included in the Move command).


Brian

--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****



------_=_NextPart_001_01BF645C.78E1DC60
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









        Sure,=20
how about a stereo headphone pr a TV set with a cable TV=20
connection
        

         
        

         
        

         
        

  
        -----Original Message-----
        From: Chuong Nguyen=20
  [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
        Sent: Friday, =
January 21,=20
  2000 4:45 PM
        To:=20
  MEGACO@standards.nortelnetworks.com
        Subject: Re: Creating =
Streams=20
  & Moving Terminations when multiple streams=20
  areactive

        Brian=20
  
        Can physical termination has multiple streams?  If yes, can =
you give=20
  me some examples.=20
  
        Thanks 
        Chuong 
         =20
  
        "Rosen, Brian" wrote:=20
  
        An issue has been raised on Streams.  =
7.1.7=20
    includes text that 
        defines when streams are created, but there =
is no=20
    text describing 
        how streams are created.  Also, the text =
does not=20
    define what happens when 
        you move a termination where there are =
multiple=20
    streams, but 
        the streams in the old and new context are not =
congruent.=20
    
        I propose the following text to be added to section 7.1.6=20
    
        Streams are created by specifying a new StreamID on one of the=20
    terminations 
        in a Context. Streams are deleted by setting the =
Mode=20
    property in 
        LocalControl to "delete" on one of the terminations =
in a=20
    Context.=20
    
        If a termination is moved from one context to another, any =
streams in the=20
    
        new context that have the same Id, and the same media (as =
determined by=20
    
        local and remote) on the moved termination remain active on =
that=20
    
        termination.  Any streams that were active on a moved =
termination=20
    that were 
        not the same StreamId and the same media type in the =
new=20
    context are deleted 
        on that termination.  Any streams on a =
moved=20
    termination that are active in 
        the new context that did not =
have the=20
    same StreamId and media type as in the 
        old context are not =
active on the=20
    termination until an update of the Media 
        descriptor on the =
termination=20
    mentioning such stream is given (which may be 
        included in the =
Move=20
    command).=20
    
        Brian
        -- 
  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
         =20


------_=_NextPart_001_01BF645C.78E1DC60--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 17:55:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18375
	for ; Fri, 21 Jan 2000 17:55:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7853D790@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:53:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2803 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 17:52:25 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E0EB93D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:42:25
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA23392 for
          ; Fri, 21 Jan 2000 17:43:53
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA20405 for
          ; Fri, 21 Jan 2000 17:43:57
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 17:41:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208815@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 17:43:49 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Completion Event for signal timeout
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It has been suggested that we have a way to find out that a signal
(or signal list) of type TIMEOUT have an event which could be
triggered when the timer expired.  We can generalize this to
completion of any signal.

I propose that we define an event in generic called sc, signal completion,
which has a parameter, a list of the names of events to
report completion.

The alternative is to add syntax to signals.  I think it's better
to make it an event - it looks like an event, acts like an event,
it is an event.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 18:00:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18423
	for ; Fri, 21 Jan 2000 18:00:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2C52F190@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:58:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2804 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 17:56:56 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8240D8D0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 17:46:56
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id RAA23738 for
          ; Fri, 21 Jan 2000 17:48:24
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id RAA21079 for
          ; Fri, 21 Jan 2000 17:48:28
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 17:45:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208817@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 17:48:19 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      DigitMaps definition & wildcard
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Suppose you wanted to define a global digitmap.  Should you
be able to say:

Context=*{Modify=*{DigitMap=NAdialPlan{"......

I would say, sure, why not.

Objections?

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 18:29:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18848
	for ; Fri, 21 Jan 2000 18:29:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3B395920@standards.nortelnetworks.com>; Fri, 21 Jan 2000 18:27:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2865 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 18:26:50 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.AEA5E920@standards.nortelnetworks.com>;
          Fri, 21 Jan 2000 18:16:48 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id RAA15871
          for ; Fri, 21 Jan 2000 17:18:02
          -0600 (CST)
Received: from relay2.dsccc.com(10.17.102.19) by fw3 via smap (V2.0) id
          xma015831; Fri, 21 Jan 00 17:17:05 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id RAA11051 for
          ; Fri, 21 Jan 2000 17:18:07
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC5B54 for
          ; Fri, 21 Jan 2000 17:17:03 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id RAA26840 for ; Fri, 21
          Jan 2000 17:16:30 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id RAA04614
          for ; Fri, 21 Jan 2000 17:16:29
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF208817@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------298AA21CD54B071F0E4D48F2"
Message-ID:  <3888E8CD.4812781@usa.alcatel.com>
Date:         Fri, 21 Jan 2000 17:16:29 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: DigitMaps definition & wildcard
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------298AA21CD54B071F0E4D48F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Depends on how many reply is received.
Why not

Context=*{Modify=ROOT{DigitMap=NAdialPlan{"......

If adding a new digitMap and assuming that terminations not in the null
context will/can use the
new digitMap since it is the default value.
Context=-{Modify=ROOT{......           // not use if ROOT can be used
here

Should Modify have a -W too?  ABNF only shows that Subtract and Audit
can have -W.
Even if Modify can have -W.  Every matching context will be returned
too.  How can one limit
the context reply to one?


Chuong

"Rosen, Brian" wrote:

> Suppose you wanted to define a global digitmap.  Should you
> be able to say:
>
> Context=*{Modify=*{DigitMap=NAdialPlan{"......
>
> I would say, sure, why not.
>
> Objections?
>
> Brian

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------298AA21CD54B071F0E4D48F2
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Depends on how many reply is received.

        Why not


        
Context=*{Modify=ROOT{DigitMap=NAdialPlan{"......

        If adding a new digitMap and assuming that terminations not in the null
context will/can use the

        new digitMap since it is the default value.

        Context=-{Modify=ROOT{......          
// not use if ROOT can be used here

        Should Modify have a -W too?  ABNF only shows that Subtract and
Audit can have -W.

        Even if Modify can have -W.  Every matching context will be returned
too.  How can one limit

        the context reply to one?

         


        
Chuong

        "Rosen, Brian" wrote:

        Suppose you wanted to define a global digitmap. 
Should you

        be able to say:

        Context=*{Modify=*{DigitMap=NAdialPlan{"......

        I would say, sure, why not.

        Objections?

        Brian
        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------298AA21CD54B071F0E4D48F2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 21:52:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21402
	for ; Fri, 21 Jan 2000 21:52:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.791BDF80@standards.nortelnetworks.com>; Fri, 21 Jan 2000 21:50:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2974 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 21:49:00 -0500
Received: from mailboy.huawei.com.cn (202.96.135.134) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.52A53950@standards.nortelnetworks.com>; Fri, 21 Jan 2000
          21:48:59 -0500
Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail
          Server v2.02) with SMTP id AAA7896; Sat, 22 Jan 2000 10:45:18 +0800
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <20000122024518.AAA7896@q17326>
Date:         Sat, 22 Jan 2000 10:51:27 +0800
Reply-To: Qiu Xiuping 
Sender: "Media Gateway Control (megaco)"
              
From: Qiu Xiuping 
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id VAA21402

Hi,  Brian£¡

  Thanks for your reply and it helps me a lot.

  It seems that  version 14 will be issued  next week .

  I think  AuditDescriptor will contain the EventBuffer Descriptor

  And how MGC use the EventBuffer , that is which command EventBuffer is used in
  is not described.

  I think it should used  in Add, Modify and Move.

At 00-1-21 11:48:00 you wrote£º
>> -----Original Message-----
>> From: Qiu Xiuping [mailto:qiuxiuping@sz.huawei.com.cn]
>> Sent: Thursday, January 20, 2000 6:31 AM
>> To: MEGACO@standards.nortelnetworks.com
>> Subject:
>>
>I have had some connectivity problems while traveling, and am way
>behind on comments to V13.  On the other hand, today is the day
>we wish to settle the text, if at all possible.
>
>I know there are other messages on this thread already, but this
>is my opinion
>
>
>
>>
>> Hi, All .
>>
>> While reading MEGACO/H.248  version 13,  I meet some questions.
>>
>> 1. In  6.2 " Terminations may be created which represent
>> multiplexed bearers, "
>>
>> I don't understand what multiplexed bearer mean.. Will you
>> please give a detailed example?
>This was answered correctly, AAL1/2, or there are several proposals
>to create a multiplexed RTP.  More than one "call" on a single
>bearer "connection"
>
>> 2. In  6.2.4   property may be declared as "Global"
>>
>> I don't know how to decalre a property as " Global", I read
>> everything but find nothing more
>> about it. And  it is the same with the " "Properties may be
>> read-only or read/write "" ,
>> there is  no  place to  declare a property to be  read-only.
>You literally say "Global" and/or "read-only",.... in the
>package definition document.  It goes in the "characteristics"
>line.  The text in section 12.1.3 needs to be modified to mention
>this.
>
>>
>>
>> 3. In 7.1.8 Local and Remote Descriptors
>> 	
>>  Local refers to the media received by the MG and Remote
>> refers to the media sent by the MG.
>>
>> I think this sentence is misfortune to be typo error. :-)
>There is some confusion here.  I think we need to align it with MGCP,
>as there is no other reason to choose, and we unnecessarily
>confuse people if they are different.  In MGCP, local specifies
>what you receive.
>
>
>>
>> 4 In 7.1.9 Events Descriptor
>>
>> The MG shall send a Notify command to the MGC when it detects
>> an event in the Events Descriptor.   "
>>
>> If so, what is the use of  eventbuffer ?
>I think this was answered.  EventsDescriptor specifies what
>to look for, ObservedEvents Descriptor tells you what has
>been detected.  EventBuffer specifies what to look for after
>you have found an event in EventsDescriptor but before the
>MGC can come back with a new EventsDescriptor.
>
>>
>> 5 In 7.2.5 AuditValue ".
>>
>> If the TerminationId is wildcarded, only one command return
>> is generated, with the contents containing the union
>> of the values of all Terminations matching the wildcard.
>> This convention may reduce the volume of data required
>> to audit a group of Terminations "
>>
>> Will you please give me a example for union of the values of
>> all Terminations matching the wildcard?
>Also answered reasonably.  Suppose I had 3 terminations A1, A2
>and A3, and let's just say there was a property pf/c which
>could have values 0-25.  Suppose A1's pf/c was currently 13,
>and A2 as well as A3 currently have pf/c set to 0.  If you did
>Context=*{W-AuditValue=A*{Audit{TerminationState}}}
>your reply might look like
>Context=*{W-AuditValue=A*{TerminationsState{...,pf/c={0,13}...
>
>>
>> 6. In 7.2.8 ServiceChange
>>
>> Restart - indicates that service will be restored on the
>> specified Terminations after expiration of the
>> ServiceChangeDelayThe MG should set serviceState to
>> "inService" upon expiry of ServiceChangeDelay
>>
>> How to deal with the bad terminations ? They can not be in "
>> inService "" of course.
>They don't get restarted!  Maybe I misunderstand the question.
>
>>
>> 7 In 8.2.2 TransactionReply
>>
>> " If the end of a command cannot be reliably determined it
>> will return 442 Syntax Error in Transaction as the reply to
>> the last action it can parse."
>>
>> It seems that "442 Syntax Error in Transaction" should be
>> corrected  to be " 442 Syntax Error in Command "  :-)
>>
>> 8 In 8.2.3 TransactionPending
>>
>> If a duplicate request is received when pending, the
>> responder may send a duplicate pending immediately,
>> or continue waiting for its timer to trigger another
>> Transaction Pending.
>>
>> My question is how to determine to choose which  method?
>It doesn't matter.  It is not necessary to send it as the
>way the timers work, you will always get a response (either
>the reply or another pending) from the original request
>before you could get one from the duplicate.  It doesn't hurt
>to get extra ones.  Your choice.
>
>Brian
>
>------------
>Brian Rosen, Principal Engineer
>Marconi (Formerly FORE Systems)
>1000 FORE Drive, Warrendale, PA 15086
>(724) 742-6826  mailto:brosen@eng.fore.com
>

Regards,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   qiuxiuping@sz.huawei.com.cn
Visit     http://www.huawei.com.cn
_______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 23:29:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22985
	for ; Fri, 21 Jan 2000 23:29:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6E40C10@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:26:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3048 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 23:25:26 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.666283B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:15:26
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA05453 for
          ; Fri, 21 Jan 2000 23:16:56
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA11863 for
          ; Fri, 21 Jan 2000 23:16:58
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 23:14:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 23:16:52 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Preconditions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megacogans!

The following issue has been raised:

Issue:          The current draft text does not support the concept of
preconditions that must be established in order for a command to be
successful. For example, the MGC and the MG can get out of synch on the
hook state. Consider a MG that just cold-started. Before the gateway
generates a restart ServiceChange, the user picks up the handset. The
gateway detects the off-hook transition, but since it does not have an
EventsDescriptor, it does not generate Notify. Soon after, the gateway
generates a restart ServiceChange. After the MGC receives the message, it
generates a Modify to the gateway to request off-hook detection. However,
since the off-hook transition has happened, the gateway does not generate
Notify. Since the gateway does not play any tone to the user, the user
hangs up the phone. Since the MGC has not requested the gateway to detect
on-hook transition, the gateway does not generate Notify either. If
preconditions were defined and supported, e.g. to require that a request
for off-hook detection would only succeed if the line state was currently
on-hook, such errors could be avoided.
Proposal:       It is strongly recommended, that preconditions as described
above are added to the draft.




Frankly, I don't think it matters a whole heck of a lot what happens in
cases
like this, unless there is some possibility that the MG and the MGC will not
sync quickly.  They do in this case -- the user hangs up, and then the state
is consistent, the next time he goes off hook, the right thing happens.  If
anyone
can define a case that doesn't converge like this, please speak now, or I
recommend
we say "thanks for sharing"


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 23:29:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22987
	for ; Fri, 21 Jan 2000 23:29:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7698FC0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:26:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3049 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 23:25:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6D5C42B0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:15:37
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA05466 for
          ; Fri, 21 Jan 2000 23:17:07
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA11885 for
          ; Fri, 21 Jan 2000 23:17:09
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 23:14:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF648F.24282598"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B29@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 23:17:02 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF648F.24282598
Content-Type: text/plain;
        charset="iso-8859-1"

I looked at this again, and I decided it was okay as it is (now).  It was
late, so maybe it only
seems to be consistent.  Other opinions?

Brian



There are really 2 methods for registration, Restart or Failover
as being the first message from MG to MGC.  Section 7.2.8 implies
only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.

Section 7.2.8 ServiceChange
"6. Failover - send from MG to MGC to indicate the primary MG is out
service and a secondary MG is taking over."
This matches section 11.4 but in section 11.5, this method is also
used by MG to register with Primary or Secondary MGC.

Does the text need to be cleaned or more clarification?
We should look at that.



Thanks
Chuong



--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****



------_=_NextPart_001_01BF648F.24282598
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









        I=20
looked at this again, and I decided it was okay as it is (now).  =
It was=20
late, so maybe it only
        

        seems=20
to be consistent.  Other opinions?
        

         
        

        Brian
        

  
         
        There are really 2 =
methods for registration, Restart or Failover
        as being the =
first message from MG to MGC.  Section 7.2.8 =
implies
        only one - Restart w/ROOT.  Section 11.5 implies =
Failover w/ROOT.
        Section 7.2.8 =
ServiceChange
        "6. Failover - send from MG to MGC to indicate =
the primary MG is out
        service and a secondary MG is taking =
over."
        This matches section 11.4 but in section 11.5, this =
method is also
        used by MG to register with Primary or =
Secondary MGC.
        Does the text need to be cleaned or =
more clarification? 
        We should =
look at that.
         
         
        Tha=
nks
        Chuong
        -- =

  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
         =20
  

------_=_NextPart_001_01BF648F.24282598--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 23:29:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22996
	for ; Fri, 21 Jan 2000 23:29:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7CDA8C0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:26:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3050 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 23:25:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6D6D0900@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:15:38
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA05468 for
          ; Fri, 21 Jan 2000 23:17:08
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA11888 for
          ; Fri, 21 Jan 2000 23:17:10
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 23:14:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B27@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 23:16:59 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Continuity Tests and National Variants
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megacogans!

The following issue has been raised:

Issue: The draft text specifies that the possible values for the
signals are "q724" and that the MG figures out whether a 2-wire or 4-wire
continuity test is to be performed on the trunk in question. First of all,
it is unclear how the MG determines precisely what continuity test variant
to perform unless it is assumed that the MG is provisioned with this
information, however this should not be a requirement. Secondly, national
variants of continuity test procedures exist, and considering the package
is a "basic continuity package" it should be possible to use this package
without requiring support for Q.724 continuity test.
Proposal: It is recommended, that the possible test values are not
specified in this basic package, but that extension packages define this
packages, similarly to the "tone generator" and "tone detection" packages
defined in Annex E.1 and E.2



I am inclined to agree, but advice from the list would be helpful.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 21 23:29:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23004
	for ; Fri, 21 Jan 2000 23:29:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E831C1C0@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:26:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3051 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 21 Jan 2000 23:25:38 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6D5C4020@standards.nortelnetworks.com>; Fri, 21 Jan 2000 23:15:37
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA05465 for
          ; Fri, 21 Jan 2000 23:17:07
          -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA11883 for
          ; Fri, 21 Jan 2000 23:17:09
          -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 21 Jan 2000 23:14:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B26@whq-msgusr-02.fore.com>
Date:         Fri, 21 Jan 2000 23:16:56 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Optional Tone Detect in a Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The following issue has been raised:

Issue: In section E.6 the draft text specifies that "Support of dA-dD is
optional". Having optional events in a package tends to defeat the purpose
of packages in the first place.
Proposal: It is recommended that either support for the signals
become mandatory or they are provided in a separate package.

Opinions?

I'd say, leave it, but I agree it's not pretty.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jan 22 09:52:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08796
	for ; Sat, 22 Jan 2000 09:52:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20BA5730@standards.nortelnetworks.com>; Sat, 22 Jan 2000 9:50:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3304 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 09:48:53 -0500
Received: from mailboy.huawei.com.cn (202.96.135.134) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E3987800@standards.nortelnetworks.com>; Sat, 22 Jan 2000
          9:48:51 -0500
Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail
          Server v2.02) with SMTP id AAA518 for
          ; Sat, 22 Jan 2000 22:44:21 +0800
X-mailer: FoxMail 3.0 beta 2 [cn]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <20000122144421.AAA518@q17326>
Date:         Sat, 22 Jan 2000 22:50:30 +0800
Reply-To: Qiu Xiuping 
Sender: "Media Gateway Control (megaco)"
              
From: Qiu Xiuping 
Subject:      Question about Protocol Version Negaotiation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi, All.

In 11.3 Negotiation of Protocol Version

1. The first ServiceChange command from MG contains a version number .
2. MGC supports only a lower version, then the MGC sends a ServiceChangeReply with the lower version . 3. If the MG is unable to comply, it will reject the association, with Error 406 Version Not Supported.

I wonder what command will MG use in step 3 .
Will it be notify? but there is no EventDescriptor.
And is it a TransactionRequest , but it is with Error code.
IMO, error code is together with TransactionReply but not TransactionRequest ?

And another question, I remember it says that MEGACO/H.248 will be compatible backwards somewhere.
Then  if both MG and MGC use the lower version, why there  still exists complying problem.


Regards,
Xiuping Qiu
_______________________________________________

Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   qiuxiuping@sz.huawei.com.cn
Visit     http://www.huawei.com.cn
_______________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jan 22 15:24:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10825
	for ; Sat, 22 Jan 2000 15:24:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.682F4110@standards.nortelnetworks.com>; Sat, 22 Jan 2000 15:21:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3523 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 22 Jan 2000 15:20:45 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.40B4BF70@standards.nortelnetworks.com>; Sat, 22 Jan 2000 15:20:45
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id MAA09506; Sat, 22 Jan
          2000 12:14:37 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id MAA22401; Sat, 22 Jan 2000 12:22:14 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14474.4469.846398.877064@thomasm-u1.cisco.com>
Date:         Sat, 22 Jan 2000 12:22:13 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Preconditions
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > Frankly, I don't think it matters a whole heck of a lot what happens in
 > cases
 > like this, unless there is some possibility that the MG and the MGC will not
 > sync quickly.

   That's a very big "unless".

 > They do in this case -- the user hangs up, and then the state
 > is consistent, the next time he goes off hook, the right thing happens.  If
 > anyone
 > can define a case that doesn't converge like this, please speak now,

   A device control protocol like MEGACO is utterly
   at the mercy of a shared view of the device's
   state. If the MG and MGC are out of sync and the
   MG has no way to convey that within the protocol,
   the protocol is broken. Period. Relagating such things
   to audits is even more broken, because MGC's in the
   real world have about zero incentive to do what
   amounts to device state polling -- which does
   not scale for high fanout devices like residential gateways.

 > I recommend we say "thanks for sharing"

   This is a base functionality of MGCP -- the
   only protocol which has any track record
   thus far. Is this more Anything But MGCP
   hubris again?

   I would say that the onus is on the naysayers
   to actually prove there does not exist any
   unrecoverable and non self-healing state
   mismatches. It is completely unreasonable for
   those who would like to have a more robust
   protocol to prove a negative.

                Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 08:57:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08931
	for ; Sun, 23 Jan 2000 08:57:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9177C220@standards.nortelnetworks.com>; 23 Jan 2000 8:55:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3777 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 08:53:45 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F51D9FE0@standards.nortelnetworks.com>; 23 Jan 2000 8:43:44
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          OAA07046; Sun, 23 Jan 2000 14:45:13 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id OAA12550;
          Sun, 23 Jan 2000 14:45:12 +0100
Received: from ericsson.com (arael25m004.ericsson.se [130.100.251.133]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          OAA05196; Sun, 23 Jan 2000 14:45:11 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B27@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388AEF83.21C628BB@ericsson.com>
Date:         Sun, 23 Jan 2000 13:09:39 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Continuity Tests and National Variants
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I say leave it how it is in the draft today. With the extend mechanisn
if people want to define a National Variant then they can extend the
current package with the values (ttypes) they like. Remember there is no
compulsion to support all the values of a property.

Regards, Christian

"Rosen, Brian" wrote:
>
> Megacogans!
>
> The following issue has been raised:
>
> Issue: The draft text specifies that the possible values for the
> signals are "q724" and that the MG figures out whether a 2-wire or 4-wire
> continuity test is to be performed on the trunk in question. First of all,
> it is unclear how the MG determines precisely what continuity test variant
> to perform unless it is assumed that the MG is provisioned with this
> information, however this should not be a requirement. Secondly, national
> variants of continuity test procedures exist, and considering the package
> is a "basic continuity package" it should be possible to use this package
> without requiring support for Q.724 continuity test.
> Proposal: It is recommended, that the possible test values are not
> specified in this basic package, but that extension packages define this
> packages, similarly to the "tone generator" and "tone detection" packages
> defined in Annex E.1 and E.2
>
> I am inclined to agree, but advice from the list would be helpful.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 08:57:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08939
	for ; Sun, 23 Jan 2000 08:57:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.923DAA30@standards.nortelnetworks.com>; 23 Jan 2000 8:55:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3779 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 08:53:47 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F6A48E00@standards.nortelnetworks.com>; 23 Jan 2000 8:43:47
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          OAA07056; Sun, 23 Jan 2000 14:45:18 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id OAA12556;
          Sun, 23 Jan 2000 14:45:18 +0100
Received: from ericsson.com (arael25m004.ericsson.se [130.100.251.133]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          OAA05204; Sun, 23 Jan 2000 14:45:17 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
            <14474.4469.846398.877064@thomasm-u1.cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388AF15F.C286A7F@ericsson.com>
Date:         Sun, 23 Jan 2000 13:17:35 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Preconditions
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Mike,

I think people are thinking of applications way past the scope of MGCP
today. Megaco  was designed to be application agnostic. Pre-conditions
depend on your application. The issue has nothing to do with protocol
robustness its about application robustness.

Christian

Michael Thomas wrote:
>
> Rosen, Brian writes:
>  > Frankly, I don't think it matters a whole heck of a lot what happens in
>  > cases
>  > like this, unless there is some possibility that the MG and the MGC will not
>  > sync quickly.
>
>    That's a very big "unless".
>
>  > They do in this case -- the user hangs up, and then the state
>  > is consistent, the next time he goes off hook, the right thing happens.  If
>  > anyone
>  > can define a case that doesn't converge like this, please speak now,
>
>    A device control protocol like MEGACO is utterly
>    at the mercy of a shared view of the device's
>    state. If the MG and MGC are out of sync and the
>    MG has no way to convey that within the protocol,
>    the protocol is broken. Period. Relagating such things
>    to audits is even more broken, because MGC's in the
>    real world have about zero incentive to do what
>    amounts to device state polling -- which does
>    not scale for high fanout devices like residential gateways.
>
>  > I recommend we say "thanks for sharing"
>
>    This is a base functionality of MGCP -- the
>    only protocol which has any track record
>    thus far. Is this more Anything But MGCP
>    hubris again?
>
>    I would say that the onus is on the naysayers
>    to actually prove there does not exist any
>    unrecoverable and non self-healing state
>    mismatches. It is completely unreasonable for
>    those who would like to have a more robust
>    protocol to prove a negative.
>
>                 Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 08:57:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08950
	for ; Sun, 23 Jan 2000 08:57:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92A1EA40@standards.nortelnetworks.com>; 23 Jan 2000 8:55:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3780 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 08:54:05 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0136B370@standards.nortelnetworks.com>; 23 Jan 2000 8:44:05
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          OAA07088; Sun, 23 Jan 2000 14:45:39 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id OAA12574;
          Sun, 23 Jan 2000 14:45:38 +0100
Received: from ericsson.com (arael25m004.ericsson.se [130.100.251.133]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          OAA05225; Sun, 23 Jan 2000 14:45:37 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20880B@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388AFD22.807248D1@ericsson.com>
Date:         Sun, 23 Jan 2000 14:07:46 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Creating Streams & Moving Terminations when multiple streams
              areactive
X-To:         "Rosen, Brian" 
X-cc:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I've got a few issues with the text. Please see below.

Christian

"Rosen, Brian" wrote:
>
> An issue has been raised on Streams.  7.1.7 includes text that
> defines when streams are created, but there is no text describing
> how streams are created.  Also, the text does not define what happens when
> you move a termination where there are multiple streams, but
> the streams in the old and new context are not congruent.
>
> I propose the following text to be added to section 7.1.6
>
> Streams are created by specifying a new StreamID on one of the terminations
> in a Context. Streams are deleted by setting the Mode property in
> LocalControl to "delete" on one of the terminations in a Context.
>
> If a termination is moved from one context to another, any streams in the
> new context that have the same Id,
>>>>> and the same media (as determined by local and remote)
[CHG] I don't believe this line should be included. The media could be
different. The MG would have to cope with this. ie. If C1(T1(S1)=GSM and
I move this to C2((T1(S1)=GSM),(T2(S1)=G711)) a transcoder should be
inserted and the call is still successful.

> on the moved termination remain active on that termination.
[CHG] This I agree with. The original stream stay active.

> Any streams that were active on a moved termination that were
> not the same StreamId
>>>>and the same media type
> in the new context are deleted on that termination.
[CHG] No these streams should just be moved. They just won't be
connected to anything. They need to still be there in case you want to
move them back.
ie. the call waiting case C1(T1 and T2 [S1=audio, S2=video]) in a audio
and video call. T2 is then moved to C2(T3 and T2 [S1=audio]) where they
are in an audio call. S2 should not be deleted because you may want to
move it back to C1.

> Any streams on a moved termination that are active in
> the new context that did not have the same StreamId
>>>>and media type
> as in the
> old context are not active on the termination until an update of the Media
> descriptor on the termination mentioning such stream is given (which may be
> included in the Move command).
[CHG] I don't understand this one.
>

[CHG] If this needs to be clarified then I propose the following text
instead of your last paragraph:
"In the case where a termination with its associated streams is moved to
a new context the following applies:
- if a stream(ID) of the moved termination matches the stream(ID) of the
existing termination the moved termination SHALL be part of the media
flow on that stream.
- if a stream(ID) of the moved termination does not match a stream(ID)
in the existing termination the stream of the moved termination SHALL be
retained although it will not take part in any media flows in the new
context.
- if a stream(ID) in the existing termination does not match a
stream(ID) in the moved termination then the existing stream continues
unaffected."

> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 09:07:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08933
	for ; Sun, 23 Jan 2000 08:57:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91D99130@standards.nortelnetworks.com>; 23 Jan 2000 8:55:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3778 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 08:53:46 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F60E6880@standards.nortelnetworks.com>; 23 Jan 2000 8:43:46
          -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          OAA07052; Sun, 23 Jan 2000 14:45:16 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id OAA12553;
          Sun, 23 Jan 2000 14:45:15 +0100
Received: from ericsson.com (arael25m004.ericsson.se [130.100.251.133]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          OAA05200; Sun, 23 Jan 2000 14:45:14 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388AF053.FFBBFFAD@ericsson.com>
Date:         Sun, 23 Jan 2000 13:13:07 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Preconditions
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Brian,

I fully agree with you. This type of information is really coupled to
different application logic. In one application this may be a problem,
in another it won't. Megaco is NOT an application protocol.

Cheers, Christian

"Rosen, Brian" wrote:
>
> Megacogans!
>
> The following issue has been raised:
>
> Issue:          The current draft text does not support the concept of
> preconditions that must be established in order for a command to be
> successful. For example, the MGC and the MG can get out of synch on the
> hook state. Consider a MG that just cold-started. Before the gateway
> generates a restart ServiceChange, the user picks up the handset. The
> gateway detects the off-hook transition, but since it does not have an
> EventsDescriptor, it does not generate Notify. Soon after, the gateway
> generates a restart ServiceChange. After the MGC receives the message, it
> generates a Modify to the gateway to request off-hook detection. However,
> since the off-hook transition has happened, the gateway does not generate
> Notify. Since the gateway does not play any tone to the user, the user
> hangs up the phone. Since the MGC has not requested the gateway to detect
> on-hook transition, the gateway does not generate Notify either. If
> preconditions were defined and supported, e.g. to require that a request
> for off-hook detection would only succeed if the line state was currently
> on-hook, such errors could be avoided.
> Proposal:       It is strongly recommended, that preconditions as described
> above are added to the draft.
>
> Frankly, I don't think it matters a whole heck of a lot what happens in
> cases
> like this, unless there is some possibility that the MG and the MGC will not
> sync quickly.  They do in this case -- the user hangs up, and then the state
> is consistent, the next time he goes off hook, the right thing happens.  If
> anyone
> can define a case that doesn't converge like this, please speak now, or I
> recommend
> we say "thanks for sharing"


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 18:18:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12305
	for ; Sun, 23 Jan 2000 18:18:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6BE3770@standards.nortelnetworks.com>; 23 Jan 2000 18:16:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4338 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 18:14:14 -0500
Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A7412A30@standards.nortelnetworks.com>; 23 Jan 2000 18:14:13 -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id PAA20319; Sun, 23
          Jan 2000 15:34:07 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id PAA22543; Sun, 23 Jan 2000 15:15:46 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF1A0B24@whq-msgusr-02.fore.com>
            <14474.4469.846398.877064@thomasm-u1.cisco.com>
            <388AF15F.C286A7F@ericsson.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14475.35746.523107.516721@thomasm-u1.cisco.com>
Date:         Sun, 23 Jan 2000 15:15:46 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Preconditions
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <388AF15F.C286A7F@ericsson.com>
Content-Transfer-Encoding: 7bit

Christian Groves writes:
 > G'Day Mike,
 >
 > I think people are thinking of applications way past the scope of MGCP
 > today. Megaco  was designed to be application agnostic. Pre-conditions
 > depend on your application. The issue has nothing to do with protocol
 > robustness its about application robustness.

   Huh?

   You're going to have to try this again, because
   this looks like a non-sequitur to me.

            Mike
 >
 > Christian
 >
 > Michael Thomas wrote:
 > >
 > > Rosen, Brian writes:
 > >  > Frankly, I don't think it matters a whole heck of a lot what happens in
 > >  > cases
 > >  > like this, unless there is some possibility that the MG and the MGC will not
 > >  > sync quickly.
 > >
 > >    That's a very big "unless".
 > >
 > >  > They do in this case -- the user hangs up, and then the state
 > >  > is consistent, the next time he goes off hook, the right thing happens.  If
 > >  > anyone
 > >  > can define a case that doesn't converge like this, please speak now,
 > >
 > >    A device control protocol like MEGACO is utterly
 > >    at the mercy of a shared view of the device's
 > >    state. If the MG and MGC are out of sync and the
 > >    MG has no way to convey that within the protocol,
 > >    the protocol is broken. Period. Relagating such things
 > >    to audits is even more broken, because MGC's in the
 > >    real world have about zero incentive to do what
 > >    amounts to device state polling -- which does
 > >    not scale for high fanout devices like residential gateways.
 > >
 > >  > I recommend we say "thanks for sharing"
 > >
 > >    This is a base functionality of MGCP -- the
 > >    only protocol which has any track record
 > >    thus far. Is this more Anything But MGCP
 > >    hubris again?
 > >
 > >    I would say that the onus is on the naysayers
 > >    to actually prove there does not exist any
 > >    unrecoverable and non self-healing state
 > >    mismatches. It is completely unreasonable for
 > >    those who would like to have a more robust
 > >    protocol to prove a negative.
 > >
 > >                 Mike
 >
 >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 19:08:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12634
	for ; Sun, 23 Jan 2000 19:08:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E5DCD3F0@standards.nortelnetworks.com>; 23 Jan 2000 19:06:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4394 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 19:05:19 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.648732B0@standards.nortelnetworks.com>; 23 Jan 2000 18:55:18 -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id SAA04909; Sun, 23 Jan
          2000 18:56:54 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id SAA00924; Sun, 23 Jan
          2000 18:56:55 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Sun, 23 Jan 2000 18:53:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20881B@whq-msgusr-02.fore.com>
Date:         Sun, 23 Jan 2000 18:56:54 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Preconditions
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Let's be careful.  I believe all of these items are defined
in packages.  I don't think there is anything like this in
the base package.  In general, we have talked about defining
events such as hook state as "edge detect", rather than state
detect.  Would it solve the problem to make such events, in
the packages, explicitly defined as change-of-state detected.
Something like "detects the transition...".

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Saturday, January 22, 2000 3:22 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Preconditions
>
>
>
>
>
> Rosen, Brian writes:
>  > Frankly, I don't think it matters a whole heck of a lot
> what happens in
>  > cases
>  > like this, unless there is some possibility that the MG
> and the MGC will not
>  > sync quickly.
>
>    That's a very big "unless".
>
>  > They do in this case -- the user hangs up, and then the state
>  > is consistent, the next time he goes off hook, the right
> thing happens.  If
>  > anyone
>  > can define a case that doesn't converge like this, please
> speak now,
>
>    A device control protocol like MEGACO is utterly
>    at the mercy of a shared view of the device's
>    state. If the MG and MGC are out of sync and the
>    MG has no way to convey that within the protocol,
>    the protocol is broken. Period. Relagating such things
>    to audits is even more broken, because MGC's in the
>    real world have about zero incentive to do what
>    amounts to device state polling -- which does
>    not scale for high fanout devices like residential gateways.
>
>  > I recommend we say "thanks for sharing"
>
>    This is a base functionality of MGCP -- the
>    only protocol which has any track record
>    thus far. Is this more Anything But MGCP
>    hubris again?
>
>    I would say that the onus is on the naysayers
>    to actually prove there does not exist any
>    unrecoverable and non self-healing state
>    mismatches. It is completely unreasonable for
>    those who would like to have a more robust
>    protocol to prove a negative.
>
>               Mike
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 20:01:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12881
	for ; Sun, 23 Jan 2000 20:01:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4EBBE350@standards.nortelnetworks.com>; 23 Jan 2000 19:59:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4435 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 19:57:52 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.217B1C30@standards.nortelnetworks.com>; 23 Jan 2000 19:57:51
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 23 Jan 2000 18:56:58 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Sun, 23
          Jan 2000 19:56:41 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sun, 23 Jan 2000 19:56:40 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6605.DFF48C5E"
Message-ID:  
Date:         Sun, 23 Jan 2000 19:56:39 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Completion Event for signal timeout
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6605.DFF48C5E
Content-Type: text/plain

If it's an optional parameter for signals it makes life a lot easier -- you
can say exactly which signal you want to get the report for with no fuss.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, January 21, 2000 5:44 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Completion Event for signal timeout
>
> It has been suggested that we have a way to find out that a signal
> (or signal list) of type TIMEOUT have an event which could be
> triggered when the timer expired.  We can generalize this to
> completion of any signal.
>
> I propose that we define an event in generic called sc, signal completion,
> which has a parameter, a list of the names of events to
> report completion.
>
> The alternative is to add syntax to signals.  I think it's better
> to make it an event - it looks like an event, acts like an event,
> it is an event.
>
> Brian

------_=_NextPart_001_01BF6605.DFF48C5E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Completion Event for signal timeout




        If it's an optional =
parameter for signals it makes life a lot easier -- you can say exactly =
which signal you want to get the report for with no fuss.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Friday, January 21, 2000 5:44 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Completion Event for signal =
timeout

          


          It has been suggested that we have a =
way to find out that a signal

          (or signal list) of type TIMEOUT have =
an event which could be

          triggered when the timer =
expired.  We can generalize this to

          completion of any signal.

          


          I propose that we define an event in =
generic called sc, signal completion,

          which has a parameter, a list of the =
names of events to

          report completion.

          


          The alternative is to add syntax to =
signals.  I think it's better

          to make it an event - it looks like =
an event, acts like an event,

          it is an event.

          


          Brian

          

        


------_=_NextPart_001_01BF6605.DFF48C5E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 20:05:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12906
	for ; Sun, 23 Jan 2000 20:05:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE9D1430@standards.nortelnetworks.com>; 23 Jan 2000 20:03:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4451 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 20:01:31 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A448FB00@standards.nortelnetworks.com>; 23 Jan 2000 20:01:31
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 23 Jan 2000 19:01:43 -0600
Received: from zrchb213.us.nortel.com by zmers013; Sun, 23 Jan 2000 20:01:37
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sun, 23 Jan 2000 19:01:36 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6606.8FC1F234"
Message-ID:  
Date:         Sun, 23 Jan 2000 19:01:34 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Optional Tone Detect in a Package
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6606.8FC1F234
Content-Type: text/plain

I'll be interested in other opinions, but I think the issue is valid.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, January 21, 2000 11:17 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Optional Tone Detect in a Package
>
> The following issue has been raised:
>
> Issue: In section E.6 the draft text specifies that "Support of dA-dD is
> optional". Having optional events in a package tends to defeat the purpose
> of packages in the first place.
> Proposal: It is recommended that either support for the signals
> become mandatory or they are provided in a separate package.
>
> Opinions?
>
> I'd say, leave it, but I agree it's not pretty.

------_=_NextPart_001_01BF6606.8FC1F234
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Optional Tone Detect in a Package




        I'll be interested =
in other opinions, but I think the issue is valid.

        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Friday, January 21, 2000 11:17 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Optional Tone Detect in a =
Package

          


          The following issue has been =
raised:

          


          Issue: In section E.6 the draft text =
specifies that "Support of dA-dD is

          optional". Having optional =
events in a package tends to defeat the purpose

          of packages in the first =
place.

          Proposal: It is recommended that =
either support for the signals

          become mandatory or they are provided =
in a separate package.

          


          Opinions?

          


          I'd say, leave it, but I agree it's =
not pretty.

          

        


------_=_NextPart_001_01BF6606.8FC1F234--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 20:13:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12952
	for ; Sun, 23 Jan 2000 20:13:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FE2B4690@standards.nortelnetworks.com>; 23 Jan 2000 20:11:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4480 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 20:09:29 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C10E4960@standards.nortelnetworks.com>; 23 Jan 2000 20:09:29
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 23 Jan 2000 19:10:18 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Sun, 23
          Jan 2000 20:10:12 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sun, 23 Jan 2000 20:10:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6607.C34D681C"
Message-ID:  
Date:         Sun, 23 Jan 2000 20:10:09 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Continuity Tests and National Variants
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6607.C34D681C
Content-Type: text/plain

I believe the assumption made in defining this package was that the MG would
be provisioned with the information required to apply the right test.  We
can see where consensus lies on this one.  The Q.724 thing certainly has to
be worked through -- it would be more consistent to assume that the flavour
of continuity test is provisioned along with the sub-type of the test.

As a general point, I'd suggest that we shouldn't try to solve everything in
v1 of the protocol; packages can be added over the next few months as needs
are identified.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Friday, January 21, 2000 11:17 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Continuity Tests and National Variants
>
> Megacogans!
>
> The following issue has been raised:
>
> Issue: The draft text specifies that the possible values for the
> signals are "q724" and that the MG figures out whether a 2-wire or 4-wire
> continuity test is to be performed on the trunk in question. First of all,
> it is unclear how the MG determines precisely what continuity test variant
> to perform unless it is assumed that the MG is provisioned with this
> information, however this should not be a requirement. Secondly, national
> variants of continuity test procedures exist, and considering the package
> is a "basic continuity package" it should be possible to use this package
> without requiring support for Q.724 continuity test.
> Proposal: It is recommended, that the possible test values are not
> specified in this basic package, but that extension packages define this
> packages, similarly to the "tone generator" and "tone detection" packages
> defined in Annex E.1 and E.2
>
>
>
> I am inclined to agree, but advice from the list would be helpful.

------_=_NextPart_001_01BF6607.C34D681C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Continuity Tests and National Variants




        I believe the =
assumption made in defining this package was that the MG would be =
provisioned with the information required to apply the right =
test.  We can see where consensus lies on this one.  The =
Q.724 thing certainly has to be worked through -- it would be more =
consistent to assume that the flavour of continuity test is provisioned =
along with the sub-type of the test.
        


        As a general point, =
I'd suggest that we shouldn't try to solve everything in v1 of the =
protocol; packages can be added over the next few months as needs are =
identified. 
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Friday, January 21, 2000 11:17 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Continuity Tests and National =
Variants

          


          Megacogans!

          


          The following issue has been =
raised:

          


          Issue: The draft text specifies that =
the possible values for the

          signals are "q724" and that =
the MG figures out whether a 2-wire or 4-wire

          continuity test is to be performed on =
the trunk in question. First of all,

          it is unclear how the MG determines =
precisely what continuity test variant

          to perform unless it is assumed that =
the MG is provisioned with this

          information, however this should not =
be a requirement. Secondly, national

          variants of continuity test =
procedures exist, and considering the package

          is a "basic continuity =
package" it should be possible to use this package

          without requiring support for Q.724 =
continuity test.

          Proposal: It is recommended, that the =
possible test values are not

          specified in this basic package, but =
that extension packages define this

          packages, similarly to the "tone =
generator" and "tone detection" packages

          defined in Annex E.1 and E.2

          

          

          


          I am inclined to agree, but advice =
from the list would be helpful.

          

        


------_=_NextPart_001_01BF6607.C34D681C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 23 20:17:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12970
	for ; Sun, 23 Jan 2000 20:17:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8E4A91E0@standards.nortelnetworks.com>; 23 Jan 2000 20:15:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4500 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 23 Jan 2000 20:14:32 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.75AF96D0@standards.nortelnetworks.com>; 23 Jan 2000 20:14:32
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 23 Jan 2000 19:15:57 -0600
Received: from zrchb213.us.nortel.com by zmers013; Sun, 23 Jan 2000 20:15:44
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sun, 23 Jan 2000 19:15:43 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6608.88AC942A"
Message-ID:  
Date:         Sun, 23 Jan 2000 19:15:41 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Question about Protocol Version Negaotiation
X-To:         Qiu Xiuping 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6608.88AC942A
Content-Type: text/plain

At this point our only backward compatibility mechanism is the fallback to
earlier version.

You make a good point: there is no message by which the MG can reject the
fallback.  The answer, it seems to me, is that it doesn't send one -- it
simply doesn't follow up on its original message and rejects any command the
MGC tries to send it.  If it connected to the MGC (e.g. via TCP) it breaks
the connection.

> -----Original Message-----
> From: Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
> Sent: Saturday, January 22, 2000 9:51 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Question about Protocol Version Negaotiation
>
> Hi, All.
>
> In 11.3 Negotiation of Protocol Version
>
> 1. The first ServiceChange command from MG contains a version number .
> 2. MGC supports only a lower version, then the MGC sends a
> ServiceChangeReply with the lower version . 3. If the MG is unable to
> comply, it will reject the association, with Error 406 Version Not
> Supported.
>
> I wonder what command will MG use in step 3 .
> Will it be notify? but there is no EventDescriptor.
> And is it a TransactionRequest , but it is with Error code.
> IMO, error code is together with TransactionReply but not
> TransactionRequest ?
>
> And another question, I remember it says that MEGACO/H.248 will be
> compatible backwards somewhere.
> Then  if both MG and MGC use the lower version, why there  still exists
> complying problem.
>
>
> Regards,
> Xiuping Qiu
> _______________________________________________
>
> Xiuping Qiu
> Huawei Technologies Co., Ltd.
> Mail to   qiuxiuping@sz.huawei.com.cn
> Visit     http://www.huawei.com.cn
> _______________________________________________

------_=_NextPart_001_01BF6608.88AC942A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Question about Protocol Version Negaotiation




        At this point our =
only backward compatibility mechanism is the fallback to earlier =
version.

        


        You make a good =
point: there is no message by which the MG can reject the =
fallback.  The answer, it seems to me, is that it doesn't send one =
-- it simply doesn't follow up on its original message and rejects any =
command the MGC tries to send it.  If it connected to the MGC =
(e.g. via TCP) it breaks the connection.
        

          

          -----Original Message-----

          From:   Qiu Xiuping =
[SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]

          Sent:   Saturday, January 22, 2000 9:51 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Question about Protocol Version =
Negaotiation

          


          Hi, All.

          


          In 11.3 Negotiation of Protocol =
Version

          


          1. The first ServiceChange command =
from MG contains a version number .

          2. MGC supports only a lower version, =
then the MGC sends a ServiceChangeReply with the lower version . 3. If =
the MG is unable to comply, it will reject the association, with Error =
406 Version Not Supported.
          


          I wonder what command will MG use in =
step 3 .

          Will it be notify? but there is no =
EventDescriptor.

          And is it a TransactionRequest , but =
it is with Error code.

          IMO, error code is together with =
TransactionReply but not TransactionRequest ?

          


          And another question, I remember it =
says that MEGACO/H.248 will be compatible backwards somewhere.

          Then  if both MG and MGC use the =
lower version, why there  still exists complying problem.

          

          


          Regards,

          Xiuping Qiu

          _______________________________________________

          


          Xiuping Qiu

          Huawei Technologies Co., Ltd.

          Mail to   =
qiuxiuping@sz.huawei.com.cn

          Visit     =
http://www.huawei.com.cn

          _______________________________________________

          

        


------_=_NextPart_001_01BF6608.88AC942A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 01:33:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19086
	for ; Mon, 24 Jan 2000 01:33:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C10F3A50@standards.nortelnetworks.com>; Mon, 24 Jan 2000 1:31:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4674 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 01:30:00 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.51D92F70@standards.nortelnetworks.com>; Mon, 24 Jan 2000 1:21:20
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA10440 for
          ; Mon, 24 Jan 2000 12:21:23
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256870.00228187 ; Mon, 24 Jan 2000 11:46:53 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256870.0022812A.00@sandesh.hss.hns.com>
Date:         Mon, 24 Jan 2000 11:50:16 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Madhu Babu 
Subject:      Moving of Termination to Null Context.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HI
     In Version 13 of H.248 Section 7.2.4 , the description of Move say that
"The Move command shall not be used to move Terminations to the Null Context",
I think there is a need to also explicitly mention that "Move command shall not
be used to move
Terminations from Null Context.".  Is there any reason to  exclude this?

regards
-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 04:45:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00399
	for ; Mon, 24 Jan 2000 04:45:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AD5A8E0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:43:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4833 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 04:42:19 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5F9A3CF0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 4:42:09
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA04046 for
          ; Mon, 24 Jan 2000 11:09:57
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256870.001BD523 ; Mon, 24 Jan 2000 10:34:00 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256870.001BC944.00@sandesh.hss.hns.com>
Date:         Mon, 24 Jan 2000 10:25:32 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Subtract Command with wildcard Termiantion Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

Regards
MadhuBabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 06:28:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01254
	for ; Mon, 24 Jan 2000 06:28:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E20FBA30@standards.nortelnetworks.com>; Mon, 24 Jan 2000 6:26:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4976 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 06:24:42 -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B334F220@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          6:24:42 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA02434
          for ; Mon, 24 Jan 2000 06:26:21
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          GAA02412 for ; Mon, 24 Jan 2000
          06:26:19 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA02143; Mon,
          24 Jan 2000 12:26:13 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          MAA02137; Mon, 24 Jan 2000 12:26:11 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <3885AE0C.8A0302A4@ficon-tech.com> <38872987.C6B26B3F@lucent.com>
            <38886633.76E014E7@ficon-tech.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C367C.AADA11AE@lucent.com>
Date:         Mon, 24 Jan 2000 12:24:44 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Comments on v13 draft
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Harpreet,

See below please,

John

Harpreet Singh Anand wrote:
>
> John,
>
> > I realize that I'm not Brian, but would like to comment on some of the
> > points you raise nevertheless :)
>
> Thanks for the reply.
>
> >
> > > 3. For audit value what is the difference between ObservedEventsDescriptor and
> > > EventBuffer Descriptor. Only
> > > EventBuffer Descriptor should be sufficient. Similarly for Audit Capabilities,
> > > what would be returned in
> > > EventBufferDescriptor ?
> >
> > Yes, there's something strange here.  How about this:
> >
> > - When EventBuffer descriptor is included in a request from MGC to MG,
> > it indicates which events the MG must detect when no Events descriptor
> > is active.
> > - When an MG is audited by means of AuditValue, it returns events that
> > are in the buffer in ObservedEvents descriptor
> > - When an MG is audited by means of AuditValue, it returns the events
> > that it will detect when no Events descriptor is active in EventBuffer
> > descriptor.
>
> I believe that in the last bullet you meant AuditCapability. But even then what will
> happen if the AuidtCpabaility is sent when the Event descriptor is active - will the
> events be sent in ObservedEvents Descriptor ?

Actually I did mean AuditValue.  I should have written "When
ObservedEvents is requested in the AuditDescriptor in AuditValue" and
"When EventBuffer is requested in the AuditDescriptor in AuditValue"
instead.

W.r.t. to your question, the draft reads "ObservedEventsDescriptor
returns the names of active events on the termination."  I don't know
what that means.

See Brian's message in this thread for comments on 4 & 5.
--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 07:09:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02176
	for ; Mon, 24 Jan 2000 07:09:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D1E4940@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:07:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4991 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:05:36 -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.69A281D0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          7:05:36 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA16112
          for ; Mon, 24 Jan 2000 07:07:14
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA16090 for ; Mon, 24 Jan 2000
          07:07:12 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA05896; Mon,
          24 Jan 2000 13:07:10 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          NAA05883; Mon, 24 Jan 2000 13:06:58 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@standards.nortelnetworks.com
References: <4FBEA8857476D311A03300204840E1CF1A0B29@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C400B.3285040F@lucent.com>
Date:         Mon, 24 Jan 2000 13:05:31 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: ServiceChange
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Brian, Chuong,

The current text in Section 7.2.8 (first sentence of sixth paragraph
after the numbered list of ServiceChangeMethods) reads "A ServiceChange
Command specifying the "Root" for the TerminationID is a registration
command [...]"  This does seem to be inconsistent with later sections.

How about changing "A ServiceChange Command specifying the "Root" for
the TerminationID and ServiceChangeMethod equal to Restart is a
registration command [...]" ?

John

     There are really 2 methods for registration, Restart or Failover

     as being the first message from MG to MGC.  Section 7.2.8 implies

     only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.

     Section 7.2.8 ServiceChange

     "6. Failover - send from MG to MGC to indicate the primary MG is
out

     service and a secondary MG is taking over."

     This matches section 11.4 but in section 11.5, this method is also

     used by MG to register with Primary or Secondary MGC.

     Does the text need to be cleaned or more clarification?

     [BR] We should look at that.


--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 07:13:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02275
	for ; Mon, 24 Jan 2000 07:13:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2CD70A90@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:11:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5004 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:09:24 -0500
Received: from auemail2.firewall.lucent.com (192.11.223.163) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F1672120@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          7:09:23 -0500
Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA17653
          for ; Mon, 24 Jan 2000 07:11:02
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA17604 for ; Mon, 24 Jan 2000
          07:10:56 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA06179; Mon,
          24 Jan 2000 13:10:56 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          NAA06175; Mon, 24 Jan 2000 13:10:55 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C40F8.8A7F57AF@lucent.com>
Date:         Mon, 24 Jan 2000 13:09:28 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Completion Event for signal timeout
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I'll second that.  If it's an event, I don't see how we can get
granularity finer than signals descriptor level.

John

> Tom-PT Taylor wrote:
>
> If it's an optional parameter for signals it makes life a lot easier
> -- you can say exactly which signal you want to get the report for
> with no fuss.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Friday, January 21, 2000 5:44 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Completion Event for signal timeout
>
>      It has been suggested that we have a way to find out that a
>      signal
>      (or signal list) of type TIMEOUT have an event which could be
>      triggered when the timer expired.  We can generalize this to
>      completion of any signal.
>
>      I propose that we define an event in generic called sc, signal
>      completion,
>      which has a parameter, a list of the names of events to
>      report completion.
>
>      The alternative is to add syntax to signals.  I think it's better
>
>      to make it an event - it looks like an event, acts like an event,
>
>      it is an event.
>
>      Brian

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 07:20:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02462
	for ; Mon, 24 Jan 2000 07:20:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2882D630@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:18:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5029 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:16:33 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F1417B40@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          7:16:33 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA12269
          for ; Mon, 24 Jan 2000 07:18:11
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA12244 for ; Mon, 24 Jan 2000
          07:18:10 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA06783; Mon,
          24 Jan 2000 13:18:09 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          NAA06779; Mon, 24 Jan 2000 13:18:07 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C42A8.A41212D8@lucent.com>
Date:         Mon, 24 Jan 2000 13:16:40 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Optional Tone Detect in a Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I don't see a big problem.  If the MGC implements the package correctly,
it knows that some tones are optional.  I will audit the MG to find out
which optional tones are supported before making assumptions about tone
support beyond the mandatory tones.

This requires an extra exchange between MGC and MG, but hopefully limits
fragmentation of packages (so we won't end up with packages defining one
tone each).

John

> Tom-PT Taylor wrote:
>
> I'll be interested in other opinions, but I think the issue is valid.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Friday, January 21, 2000 11:17 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Optional Tone Detect in a Package
>
>      The following issue has been raised:
>
>      Issue: In section E.6 the draft text specifies that "Support of
>      dA-dD is
>      optional". Having optional events in a package tends to defeat
>      the purpose
>      of packages in the first place.
>      Proposal: It is recommended that either support for the signals
>      become mandatory or they are provided in a separate package.
>
>      Opinions?
>
>      I'd say, leave it, but I agree it's not pretty.

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 07:28:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02812
	for ; Mon, 24 Jan 2000 07:28:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47A80D90@standards.nortelnetworks.com>; Mon, 24 Jan 2000 7:26:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5047 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 07:24:47 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.17EF8FB0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          7:24:47 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA15884
          for ; Mon, 24 Jan 2000 07:26:26
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA15873 for ; Mon, 24 Jan 2000
          07:26:25 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA07782; Mon,
          24 Jan 2000 13:26:24 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          NAA07755; Mon, 24 Jan 2000 13:26:17 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@standards.nortelnetworks.com
References: <65256870.0022812A.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C4492.7F408638@lucent.com>
Date:         Mon, 24 Jan 2000 13:24:50 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Moving of Termination to Null Context.
X-To:         bmbabu@hss.hns.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Madhu,

I changed the text to "The Move command shall not be used to move
Terminations to or from the Null Context."  Is that okay?

John

Madhu Babu wrote:
>
> HI
>      In Version 13 of H.248 Section 7.2.4 , the description of Move say that
> "The Move command shall not be used to move Terminations to the Null Context",
> I think there is a need to also explicitly mention that "Move command shall not
> be used to move
> Terminations from Null Context.".  Is there any reason to  exclude this?
>
> regards
> -Madhubabu

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 09:52:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09035
	for ; Mon, 24 Jan 2000 09:52:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.529EAA10@standards.nortelnetworks.com>; Mon, 24 Jan 2000 9:49:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5298 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 09:48:39 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.C9089B90@standards.nortelnetworks.com>;
          Mon, 24 Jan 2000 9:38:35 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id IAA06699
          for ; Mon, 24 Jan 2000 08:39:51
          -0600 (CST)
Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma006602; Mon, 24 Jan 00 08:39:22 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id IAA00872 for
          ; Mon, 24 Jan 2000 08:39:20
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC6714 for
          ; Mon, 24 Jan 2000 08:39:20 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id IAA22759 for ; Mon, 24
          Jan 2000 08:39:07 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA07383
          for ; Mon, 24 Jan 2000 08:39:07
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B29@whq-msgusr-02.fore.com>
            <388C400B.3285040F@lucent.com>
Content-Type: multipart/alternative;
              boundary="------------34243E6904221265238990B0"
Message-ID:  <388C640B.BC1D28D8@usa.alcatel.com>
Date:         Mon, 24 Jan 2000 08:39:07 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------34243E6904221265238990B0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

For either Restart or Failover, one would still has to specify ROOT at the
terminationID.
Also both methods really resulted in a registration since the MGC
receiving this ServiceChange
can still deny the registering MG.

If you want to change the text then it should be
"A ServiceChange Command specifying the "Root" for
the TerminationID and ServiceChangeMethod equal to Restart or Failover is
a
registration command [...]"

Chuong


John Segers wrote:

> Brian, Chuong,
>
> The current text in Section 7.2.8 (first sentence of sixth paragraph
> after the numbered list of ServiceChangeMethods) reads "A ServiceChange
> Command specifying the "Root" for the TerminationID is a registration
> command [...]"  This does seem to be inconsistent with later sections.
>
> How about changing "A ServiceChange Command specifying the "Root" for
> the TerminationID and ServiceChangeMethod equal to Restart is a
> registration command [...]" ?
>
> John
>
>      There are really 2 methods for registration, Restart or Failover
>
>      as being the first message from MG to MGC.  Section 7.2.8 implies
>
>      only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.
>
>      Section 7.2.8 ServiceChange
>
>      "6. Failover - send from MG to MGC to indicate the primary MG is
> out
>
>      service and a secondary MG is taking over."
>
>      This matches section 11.4 but in section 11.5, this method is also
>
>      used by MG to register with Primary or Secondary MGC.
>
>      Does the text need to be cleaned or more clarification?
>
>      [BR] We should look at that.
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------34243E6904221265238990B0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



For either Restart or Failover, one would still has to specify ROOT at
the terminationID.

        Also both methods really resulted in a registration since the MGC receiving
this ServiceChange

        can still deny the registering MG.

        If you want to change the text then it should be

        "A ServiceChange Command specifying the "Root" for

        the TerminationID and ServiceChangeMethod equal to Restart or Failover
is a

        registration command [...]"

        Chuong

         

        John Segers wrote:

        Brian, Chuong,

        The current text in Section 7.2.8 (first sentence of sixth paragraph

        after the numbered list of ServiceChangeMethods) reads "A ServiceChange

        Command specifying the "Root" for the TerminationID is a registration

        command [...]"  This does seem to be inconsistent with later sections.

        How about changing "A ServiceChange Command specifying the "Root" for

        the TerminationID and ServiceChangeMethod equal to Restart is a

        registration command [...]" ?

        John

             There are really 2 methods for registration,
Restart or Failover

             as being the first message from MG to MGC. 
Section 7.2.8 implies

             only one - Restart w/ROOT.  Section 11.5
implies Failover w/ROOT.

             Section 7.2.8 ServiceChange

             "6. Failover - send from MG to MGC to indicate
the primary MG is

        out

             service and a secondary MG is taking over."

             This matches section 11.4 but in section 11.5,
this method is also

             used by MG to register with Primary or Secondary
MGC.

             Does the text need to be cleaned or more clarification?

             [BR] We should look at that.

        --

        John Segers                                 
email: jsegers@lucent.com

        Lucent Technologies                                       
Room HE 306

        Dept. Forward Looking Work                     
phone: +31 35 687 4724

        P.O. Box 18, 1270 AA  Huizen                     
fax: +31 35 687 5954
        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------34243E6904221265238990B0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 10:10:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09948
	for ; Mon, 24 Jan 2000 10:10:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8C0D210@standards.nortelnetworks.com>; Mon, 24 Jan 2000 10:07:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5373 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:06:06 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A0AFF220@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          10:06:05 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 09:06:21 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 24
          Jan 2000 10:05:58 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 24 Jan 2000 10:05:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF667C.8429CAD4"
Message-ID:  
Date:         Mon, 24 Jan 2000 10:05:37 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Subtract Command with wildcard Termiantion Name
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF667C.8429CAD4
Content-Type: text/plain

Your question has a couple of wider implications.  My first reaction was to
say this was an error, because in principle the MGC can always know which
context a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine the
current context of a termination if it doesn't know it already.

I think the answer has to be that we change the production auditOther to
include the context ID.

e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

Then the answer to your original question is that it is an error.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Sunday, January 23, 2000 11:56 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Subtract Command with wildcard Termiantion Name
>
> Hi!
>      Here is a small query regarding the case where ContextID is "*" and
> Termination Name is fully-specified. Does this implies that MGC intends to
> Subtract the specific termination from
> "whichever" context it appears in ? Or it is an error because a
> termination can
> exist only in one context and
> ContextID = "*" for a specific termination is an error ?
>
> Regards
> MadhuBabu

------_=_NextPart_001_01BF667C.8429CAD4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Subtract Command with wildcard Termiantion Name




        Your question has a =
couple of wider implications.  My first reaction was to say this =
was an error, because in principle the MGC can always know which =
context a termination is in, through audits if necessary.  Then I =
checked out our audit response syntax and realized that the MGC cannot =
determine the current context of a termination if it doesn't know it =
already.
        


        I think the answer =
has to be that we change the production auditOther to include the =
context ID.

          

        e.g. auditOther =3D EQUAL TerminationID =
LBRKT  CtxToken EQUAL =
ContextID  terminationAudit RBRKT

        


        Then the answer to =
your original question is that it is an error.

        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Sunday, January 23, 2000 11:56 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Subtract Command with wildcard =
Termiantion Name

          


          Hi!

               Here is a =
small query regarding the case where ContextID is "*" =
and

          Termination Name is fully-specified. =
Does this implies that MGC intends to

          Subtract the specific termination =
from

          "whichever" context it =
appears in ? Or it is an error because a termination can

          exist only in one context and

          ContextID =3D "*" for a =
specific termination is an error ?

          


          Regards

          MadhuBabu

          

        


------_=_NextPart_001_01BF667C.8429CAD4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 10:18:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10253
	for ; Mon, 24 Jan 2000 10:18:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F7FB6630@standards.nortelnetworks.com>; Mon, 24 Jan 2000 10:15:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5393 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:15:22 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.EC310EE0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          10:15:22 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 09:16:48 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 24
          Jan 2000 10:16:29 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 24 Jan 2000 10:16:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF667D.FCD16B12"
Message-ID:  
Date:         Mon, 24 Jan 2000 10:16:20 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Moving of Termination to Null Context.
X-To:         bmbabu@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF667D.FCD16B12
Content-Type: text/plain

Good point.  The sentence should read "The Move command shall not be used to
move Terminations to or from the Null Context".

I'd say the reason to exclude the Move in each case is to make clear that
the Null context is really a syntactic convenience and does not have the
same characteristics as other contexts.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Monday, January 24, 2000 1:20 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Moving of Termination to Null Context.
>
> HI
>      In Version 13 of H.248 Section 7.2.4 , the description of Move say
> that
> "The Move command shall not be used to move Terminations to the Null
> Context",
> I think there is a need to also explicitly mention that "Move command
> shall not
> be used to move
> Terminations from Null Context.".  Is there any reason to  exclude this?
>
> regards
> -Madhubabu

------_=_NextPart_001_01BF667D.FCD16B12
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Moving of Termination to Null Context.




        Good point.  =
The sentence should read "The =
Move command shall not be used to move Terminations to or from the Null =
Context".
        


        I'd say the reason to exclude the Move =
in each case is to make clear that the Null context is really a =
syntactic convenience and does not have the same characteristics as =
other contexts.  
        

          

          -----Original Message-----

          From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]

          Sent:   Monday, January 24, 2000 1:20 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Moving of Termination to Null =
Context.

          


          HI

               In Version =
13 of H.248 Section 7.2.4 , the description of Move say that

          "The Move command shall not be =
used to move Terminations to the Null Context",

          I think there is a need to also =
explicitly mention that "Move command shall not

          be used to move

          Terminations from Null =
Context.".  Is there any reason to  exclude this?

          


          regards

          -Madhubabu

          

        


------_=_NextPart_001_01BF667D.FCD16B12--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 10:35:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11035
	for ; Mon, 24 Jan 2000 10:35:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A63BE10@standards.nortelnetworks.com>; Mon, 24 Jan 2000 10:32:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5432 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:31:44 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.3597E1B0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          10:31:44 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 09:32:58 -0600
Received: from zcard00m.ca.nortel.com by zmers013; Mon, 24 Jan 2000 10:32:40
          -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version
          5.5.2448.0) id DLZ5R2DH; Mon, 24 Jan 2000 10:32:40 -0500
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by
          zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2448.0) id DMXA2GHR; Mon, 24 Jan 2000 10:32:40
          -0500
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20881B@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388C70FD.2D613F4F@americasm01.nt.com>
Date:         Mon, 24 Jan 2000 10:34:21 -0500
Reply-To: Abdallah Rayhan 
Sender: "Media Gateway Control (megaco)"
              
From: Abdallah Rayhan 
Organization: Nortel Networks
Subject:      Re: Preconditions
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I agree with you that caution should be exerted when introducing
this feature. The main problem is syncing MGC and MG. If there is
one state that the MGC and MG could agree upon then it should be
used to sync the two. Why look for keypad events if the phone is onhook
?
Other events are dropped. Such an event is very much related to the
application and the package(s) the termination implements. But defining
application interaction is outside the scope of the protocol (IMO).

How do we resolve this ? Allow manual provisioning of Notify.
This would allow the application to exert flexibility in its interaction

with the protocol.

Abdallah

"Rosen, Brian" wrote:

> Let's be careful.  I believe all of these items are defined
> in packages.  I don't think there is anything like this in
> the base package.  In general, we have talked about defining
> events such as hook state as "edge detect", rather than state
> detect.  Would it solve the problem to make such events, in
> the packages, explicitly defined as change-of-state detected.
> Something like "detects the transition...".
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Saturday, January 22, 2000 3:22 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Preconditions
> >
> >
> >
> >
> >
> > Rosen, Brian writes:
> >  > Frankly, I don't think it matters a whole heck of a lot
> > what happens in
> >  > cases
> >  > like this, unless there is some possibility that the MG
> > and the MGC will not
> >  > sync quickly.
> >
> >    That's a very big "unless".
> >
> >  > They do in this case -- the user hangs up, and then the state
> >  > is consistent, the next time he goes off hook, the right
> > thing happens.  If
> >  > anyone
> >  > can define a case that doesn't converge like this, please
> > speak now,
> >
> >    A device control protocol like MEGACO is utterly
> >    at the mercy of a shared view of the device's
> >    state. If the MG and MGC are out of sync and the
> >    MG has no way to convey that within the protocol,
> >    the protocol is broken. Period. Relagating such things
> >    to audits is even more broken, because MGC's in the
> >    real world have about zero incentive to do what
> >    amounts to device state polling -- which does
> >    not scale for high fanout devices like residential gateways.
> >
> >  > I recommend we say "thanks for sharing"
> >
> >    This is a base functionality of MGCP -- the
> >    only protocol which has any track record
> >    thus far. Is this more Anything But MGCP
> >    hubris again?
> >
> >    I would say that the onus is on the naysayers
> >    to actually prove there does not exist any
> >    unrecoverable and non self-healing state
> >    mismatches. It is completely unreasonable for
> >    those who would like to have a more robust
> >    protocol to prove a negative.
> >
> >               Mike
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 10:48:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11493
	for ; Mon, 24 Jan 2000 10:48:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2DAE3510@standards.nortelnetworks.com>; Mon, 24 Jan 2000 10:45:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5473 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:45:19 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.1B8E9EB0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          10:45:19 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 09:46:02 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 24
          Jan 2000 10:45:42 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 24 Jan 2000 10:45:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6682.108ABC54"
Message-ID:  
Date:         Mon, 24 Jan 2000 10:45:38 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Completion Event for signal timeout
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6682.108ABC54
Content-Type: text/plain

What I've realized, thinking things over, is that we have to define two
different things: how to activate reporting of the completion event, and how
to report it.  The optional signal parameter activates it.  A generic
completion event would report it.  There are two cases: reporting a simple
signal completion, and reporting completion of a signal list.  The first is
all we really need, since the second can be achieved by reporting the
completion of the last signal in the list.

> -----Original Message-----
> From: John Segers [SMTP:jsegers@LUCENT.COM]
> Sent: Monday, January 24, 2000 7:09 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Completion Event for signal timeout
>
> I'll second that.  If it's an event, I don't see how we can get
> granularity finer than signals descriptor level.
>
> John
>
> > Tom-PT Taylor wrote:
> >
> > If it's an optional parameter for signals it makes life a lot easier
> > -- you can say exactly which signal you want to get the report for
> > with no fuss.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Friday, January 21, 2000 5:44 PM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Completion Event for signal timeout
> >
> >      It has been suggested that we have a way to find out that a
> >      signal
> >      (or signal list) of type TIMEOUT have an event which could be
> >      triggered when the timer expired.  We can generalize this to
> >      completion of any signal.
> >
> >      I propose that we define an event in generic called sc, signal
> >      completion,
> >      which has a parameter, a list of the names of events to
> >      report completion.
> >
> >      The alternative is to add syntax to signals.  I think it's better
> >
> >      to make it an event - it looks like an event, acts like an event,
> >
> >      it is an event.
> >
> >      Brian
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

------_=_NextPart_001_01BF6682.108ABC54
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Completion Event for signal timeout




        What I've realized, =
thinking things over, is that we have to define two different things: =
how to activate reporting of the completion event, and how to report =
it.  The optional signal parameter activates it.  A generic =
completion event would report it.  There are two cases: reporting =
a simple signal completion, and reporting completion of a signal =
list.  The first is all we really need, since the second can be =
achieved by reporting the completion of the last signal in the =
list.
        

          

          -----Original Message-----

          From:   John Segers [SMTP:jsegers@LUCENT.COM]

          Sent:   Monday, January 24, 2000 7:09 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Completion Event for signal =
timeout

          


          I'll second that.  If it's an =
event, I don't see how we can get

          granularity finer than signals =
descriptor level.

          


          John

          


          > Tom-PT Taylor wrote:

          >

          > If it's an optional parameter =
for signals it makes life a lot easier

          > -- you can say exactly which =
signal you want to get the report for

          > with no fuss.

          >

          >      =
-----Original Message-----

          >      =
From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          >      =
Sent:   Friday, January 21, 2000 5:44 PM

          >      =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          >      =
Subject:        Completion Event for =
signal timeout

          >

          >      It =
has been suggested that we have a way to find out that a

          >      =
signal

          >      =
(or signal list) of type TIMEOUT have an event which could be

          >      =
triggered when the timer expired.  We can generalize this =
to

          >      =
completion of any signal.

          >

          >      I =
propose that we define an event in generic called sc, signal

          >      =
completion,

          >      =
which has a parameter, a list of the names of events to

          >      =
report completion.

          >

          >      =
The alternative is to add syntax to signals.  I think it's =
better

          >

          >      to =
make it an event - it looks like an event, acts like an event,

          >

          >      it =
is an event.

          >

          >      =
Brian

          


          --

          John =
Segers           =
            =
           email: =
jsegers@lucent.com

          Lucent =
Technologies          =
            =
            =
      Room HE 306

          Dept. Forward Looking =
Work           &n=
bsp;          phone: +31 =
35 687 4724

          P.O. Box 18, 1270 AA  =
Huizen           =
           fax: +31 =
35 687 5954

          

        


------_=_NextPart_001_01BF6682.108ABC54--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 11:00:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11869
	for ; Mon, 24 Jan 2000 11:00:17 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DCEDFCD0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 10:57:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5482 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 10:56:57 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.4DE2D610@standards.nortelnetworks.com>;
          Mon, 24 Jan 2000 10:46:43 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id JAA17528
          for ; Mon, 24 Jan 2000 09:47:43
          -0600 (CST)
Received: from relay1.dsccc.com(10.17.102.29) by fw3 via smap (V2.0) id
          xma017187; Mon, 24 Jan 00 09:45:24 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id JAA05637 for
          ; Mon, 24 Jan 2000 09:45:20
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC4349 for
          ; Mon, 24 Jan 2000 09:45:20 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id JAA06472 for ; Mon, 24
          Jan 2000 09:44:43 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA07401
          for ; Mon, 24 Jan 2000 09:44:43
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------BD3D050EA385828FF322F50B"
Message-ID:  <388C736B.F2C179A8@usa.alcatel.com>
Date:         Mon, 24 Jan 2000 09:44:43 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Subtract Command with wildcard Termiantion Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------BD3D050EA385828FF322F50B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom

In response to the Subtract query.
I think that it is NOT an error since a termination can only be in one
context at a time.  Therefore,
the MG finds out which context the termination is in and subtracts that
termination.

            Context = * {Subtract = T123}        // request
            Context = 100 {Subtract = T123}    // reply.  T123 found in
Context 100 and was subtracted

Otherwise, if it is an error, is it a syntax error or exceution of the
Subtract command error?

If it is a syntax error, the ABNF has to be changed somehow to reflect
that for Subtract
contextID has to be fully specified if the terminationID is fully
specified.  All these could get
very complicated for the ABNF parser.
Does this mean that Context = * {Subtract =*} is invalid now?

If it is a command execution error, then it is an implementation issue.
I don't see why an MG
can't find the conext that contains the terminationId to subtract from.

Chuong

Tom-PT Taylor wrote:

>
>
> Your question has a couple of wider implications.  My first reaction
> was to say this was an error, because in principle the MGC can always
> know which context a termination is in, through audits if necessary.
> Then I checked out our audit response syntax and realized that the MGC
> cannot determine the current context of a termination if it doesn't
> know it already.
>
> I think the answer has to be that we change the production auditOther
> to include the context ID.
>
> e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
> terminationAudit RBRKT
>
> Then the answer to your original question is that it is an error.
>
>      -----Original Message-----
>      From:  Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>      Sent:  Sunday, January 23, 2000 11:56 PM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       Subtract Command with wildcard Termiantion Name
>
>      Hi!
>           Here is a small query regarding the case where ContextID is
>      "*" and
>      Termination Name is fully-specified. Does this implies that MGC
>      intends to
>      Subtract the specific termination from
>      "whichever" context it appears in ? Or it is an error because a
>      termination can
>      exist only in one context and
>      ContextID = "*" for a specific termination is an error ?
>
>      Regards
>      MadhuBabu
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------BD3D050EA385828FF322F50B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Tom

        In response to the Subtract query.

        I think that it is NOT an error since a termination can only be
in one context at a time.  Therefore,

        the MG finds out which context the termination is in and subtracts
that termination.

                    Context
= * {Subtract = T123}        // request

                   
Context = 100 {Subtract = T123}    // reply.  T123
found in Context 100 and was subtracted

        Otherwise, if it is an error, is it a syntax error or exceution of the
Subtract command error?

        If it is a syntax error, the ABNF has to be changed somehow to reflect
that for Subtract

        contextID has to be fully specified if the terminationID is fully specified. 
All these could get

        very complicated for the ABNF parser.

        Does this mean that Context = * {Subtract =*} is invalid now?

        If it is a command execution error, then it is an implementation issue. 
I don't see why an MG

        can't find the conext that contains the terminationId to subtract from.

        Chuong

        Tom-PT Taylor wrote:

         

        Your question
has a couple of wider implications.  My first reaction was to say
this was an error, because in principle the MGC can always know which context
a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine
the current context of a termination if it doesn't know it already.

        I think the answer
has to be that we change the production auditOther to include the context
ID.

        e.g.auditOther
= EQUAL TerminationID LBRKT 
CtxToken EQUAL ContextID  terminationAudit RBRKT

        Then the answer
to your original question is that it is an error.

          -----Original Message-----

          From:  Sachin Mittal [SMTP:samittal@HSS.HNS.COM]

          Sent:  Sunday, January
23, 2000 11:56 PM

          To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:      
Subtract Command with wildcard Termiantion Name

          Hi!

               Here is a
small query regarding the case where ContextID is "*" and

          Termination Name is fully-specified.
Does this implies that MGC intends to

          Subtract the specific termination
from

          "whichever" context it appears in
? Or it is an error because a termination can

          exist only in one context and

          ContextID = "*" for a specific termination
is an error ?

          Regards

          MadhuBabu
        

        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------BD3D050EA385828FF322F50B--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 11:08:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12197
	for ; Mon, 24 Jan 2000 11:08:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FCB085A0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 11:05:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5535 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 11:04:32 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CA8755E0@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          11:04:32 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 10:05:44 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 24 Jan 2000 11:05:30
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 24 Jan 2000 10:05:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6684.D46FD1FC"
Message-ID:  <29400B68197CD31188830000F8CD15D343BBC7@zcard00q.ca.nortel.com>
Date:         Mon, 24 Jan 2000 10:05:25 -0600
Reply-To: Peter Blatherwick 
Sender: "Media Gateway Control (megaco)"
              
From: Peter Blatherwick 
Subject:      Re: Preconditions
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6684.D46FD1FC
Content-Type: text/plain

My 0.02...

First, we must avoid application dependencies in the protocol itself.
Therefore setting pre-conditions as part of the base protocol, especially if
they are aimed at particular events or signals, is not a good idea IMHO.  I
think anything along these lines should be solved in package definitions
since they are at least concerned with application level information
exchange.  I don't think anyone is asking for anything other than careful
package definition, but thought I should say this anyway.

However, I do see the "invisible state transition problem" as potentially
serious in at least some cases.  I think the best way to solve this in
general is to define, in the affected packages, the detection event as
"detects transition to or already in the requested state".  This would
detect the edge OR if the state already exists.  (I'm pretty sure this is
old ground, but darned if I can find the old thread right now.)

-- Peter

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: 23 Jan, 2000 18:57
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Preconditions
>
> Let's be careful.  I believe all of these items are defined
> in packages.  I don't think there is anything like this in
> the base package.  In general, we have talked about defining
> events such as hook state as "edge detect", rather than state
> detect.  Would it solve the problem to make such events, in
> the packages, explicitly defined as change-of-state detected.
> Something like "detects the transition...".
>
> Brian
>
> > -----Original Message-----
> > From: Michael Thomas [mailto:mat@cisco.com]
> > Sent: Saturday, January 22, 2000 3:22 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Preconditions
> >
> >
> >
> >
> >
> > Rosen, Brian writes:
> >  > Frankly, I don't think it matters a whole heck of a lot
> > what happens in
> >  > cases
> >  > like this, unless there is some possibility that the MG
> > and the MGC will not
> >  > sync quickly.
> >
> >    That's a very big "unless".
> >
> >  > They do in this case -- the user hangs up, and then the state
> >  > is consistent, the next time he goes off hook, the right
> > thing happens.  If
> >  > anyone
> >  > can define a case that doesn't converge like this, please
> > speak now,
> >
> >    A device control protocol like MEGACO is utterly
> >    at the mercy of a shared view of the device's
> >    state. If the MG and MGC are out of sync and the
> >    MG has no way to convey that within the protocol,
> >    the protocol is broken. Period. Relagating such things
> >    to audits is even more broken, because MGC's in the
> >    real world have about zero incentive to do what
> >    amounts to device state polling -- which does
> >    not scale for high fanout devices like residential gateways.
> >
> >  > I recommend we say "thanks for sharing"
> >
> >    This is a base functionality of MGCP -- the
> >    only protocol which has any track record
> >    thus far. Is this more Anything But MGCP
> >    hubris again?
> >
> >    I would say that the onus is on the naysayers
> >    to actually prove there does not exist any
> >    unrecoverable and non self-healing state
> >    mismatches. It is completely unreasonable for
> >    those who would like to have a more robust
> >    protocol to prove a negative.
> >
> >               Mike
> >

------_=_NextPart_001_01BF6684.D46FD1FC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Preconditions




        My 0.02...

        


        First, we must avoid =
application dependencies in the protocol itself.  Therefore =
setting pre-conditions as part of the base protocol, especially if they =
are aimed at particular events or signals, is not a good idea =
IMHO.  I think anything along these lines should be solved in =
package definitions since they are at least concerned with application =
level information exchange.  I don't think anyone is asking for =
anything other than careful package definition, but thought I should =
say this anyway.  
        


        However, I do see =
the "invisible state transition problem" as potentially =
serious in at least some cases.  I think the best way to solve =
this in general is to define, in the affected packages, the detection =
event as "detects transition to or already in the requested =
state".  This would detect the edge OR if the state already =
exists.  (I'm pretty sure this is old ground, but darned if I can =
find the old thread right now.)  
        


        -- Peter

        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   23 Jan, 2000 18:57

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Preconditions

          


          Let's be careful.  I believe all =
of these items are defined

          in packages.  I don't think =
there is anything like this in

          the base package.  In general, =
we have talked about defining

          events such as hook state as =
"edge detect", rather than state

          detect.  Would it solve the =
problem to make such events, in

          the packages, explicitly defined as =
change-of-state detected.

          Something like "detects the =
transition...".

          


          Brian

          


          > -----Original Message-----

          > From: Michael Thomas =
[mailto:mat@cisco.com]

          > Sent: Saturday, January 22, 2000 =
3:22 PM

          > To: Rosen, Brian

          > Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          > Subject: Preconditions

          >

          >

          >

          >

          >

          > Rosen, Brian writes:

          >  > Frankly, I don't =
think it matters a whole heck of a lot

          > what happens in

          >  > cases

          >  > like this, unless =
there is some possibility that the MG

          > and the MGC will not

          >  > sync quickly.

          >

          >    That's a very =
big "unless".

          >

          >  > They do in this case =
-- the user hangs up, and then the state

          >  > is consistent, the =
next time he goes off hook, the right

          > thing happens.  If

          >  > anyone

          >  > can define a case =
that doesn't converge like this, please

          > speak now,

          >

          >    A device =
control protocol like MEGACO is utterly

          >    at the mercy =
of a shared view of the device's

          >    state. If the =
MG and MGC are out of sync and the

          >    MG has no way =
to convey that within the protocol,

          >    the protocol =
is broken. Period. Relagating such things

          >    to audits is =
even more broken, because MGC's in the

          >    real world =
have about zero incentive to do what

          >    amounts to =
device state polling -- which does

          >    not scale for =
high fanout devices like residential gateways.

          >

          >  > I recommend we say =
"thanks for sharing"

          >

          >    This is a base =
functionality of MGCP -- the

          >    only protocol =
which has any track record

          >    thus far. Is =
this more Anything But MGCP

          >    hubris =
again?

          >

          >    I would say =
that the onus is on the naysayers

          >    to actually =
prove there does not exist any

          >    unrecoverable =
and non self-healing state

          >    mismatches. It =
is completely unreasonable for

          >    those who =
would like to have a more robust

          >    protocol to =
prove a negative.

          >

          >         =
;      Mike

          >

          

        


------_=_NextPart_001_01BF6684.D46FD1FC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 12:36:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15761
	for ; Mon, 24 Jan 2000 12:36:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5619F6B0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:34:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 5759 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 12:33:12 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.2D434070@standards.nortelnetworks.com>; Mon, 24 Jan 2000 12:33:11
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id KAA24346; Mon, 24 Jan 2000 10:33:45
          -0700 (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------E3E3C68F788CAA708BCDD5CA"
Message-ID:  <388C8CD9.ED1CD8BF@aztek-eng.com>
Date:         Mon, 24 Jan 2000 10:33:13 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      Re: Question about Protocol Version Negaotiation
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------E3E3C68F788CAA708BCDD5CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a simple, related question. Where is the current MEGACO
protocol version identified in the spec? Seems like this is
missing.

Tom-PT Taylor wrote:

>
>
> At this point our only backward compatibility mechanism is the
> fallback to earlier version.
>
> You make a good point: there is no message by which the MG can
> reject the fallback.  The answer, it seems to me, is that it
> doesn't send one -- it simply doesn't follow up on its original
> message and rejects any command the MGC tries to send it.  If
> it connected to the MGC (e.g. via TCP) it breaks the
> connection.
>
>      -----Original Message-----
>      From:   Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
>      Sent:   Saturday, January 22, 2000 9:51 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Question about Protocol Version
>      Negaotiation
>
>      Hi, All.
>
>      In 11.3 Negotiation of Protocol Version
>
>      1. The first ServiceChange command from MG contains a
>      version number .
>      2. MGC supports only a lower version, then the MGC sends a
>      ServiceChangeReply with the lower version . 3. If the MG
>      is unable to comply, it will reject the association, with
>      Error 406 Version Not Supported.
>
>      I wonder what command will MG use in step 3 .
>      Will it be notify? but there is no EventDescriptor.
>      And is it a TransactionRequest , but it is with Error
>      code.
>      IMO, error code is together with TransactionReply but not
>      TransactionRequest ?
>
>      And another question, I remember it says that MEGACO/H.248
>      will be compatible backwards somewhere.
>      Then  if both MG and MGC use the lower version, why there
>      still exists complying problem.
>
>      Regards,
>      Xiuping Qiu
>      _______________________________________________
>
>      Xiuping Qiu
>      Huawei Technologies Co., Ltd.
>      Mail to   qiuxiuping@sz.huawei.com.cn
>      Visit     http://www.huawei.com.cn
>      _______________________________________________
>

--------------E3E3C68F788CAA708BCDD5CA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



I have a simple, related question. Where is the current MEGACO protocol
version identified in the spec? Seems like this is missing.

        Tom-PT Taylor wrote:

         

        At this point
our only backward compatibility mechanism is the fallback to earlier version.

        You make a good
point: there is no message by which the MG can reject the fallback. 
The answer, it seems to me, is that it doesn't send one -- it simply doesn't
follow up on its original message and rejects any command the MGC tries
to send it.  If it connected to the MGC (e.g. via TCP) it breaks the
connection.

          -----Original Message-----

          From:  
Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]

          Sent:  
Saturday, January 22, 2000 9:51 AM

          To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       
Question about Protocol Version Negaotiation

          Hi, All.

          In 11.3 Negotiation of Protocol Version

          1. The first ServiceChange command
from MG contains a version number .

          2. MGC supports only a lower version,
then the MGC sends a ServiceChangeReply with the lower version . 3. If
the MG is unable to comply, it will reject the association, with Error
406 Version Not Supported.

          I wonder what command will MG use in
step 3 .

          Will it be notify? but there is no
EventDescriptor.

          And is it a TransactionRequest , but
it is with Error code.

          IMO, error code is together with TransactionReply
but not TransactionRequest ?

          And another question, I remember it
says that MEGACO/H.248 will be compatible backwards somewhere.

          Then  if both MG and MGC use
the lower version, why there  still exists complying problem.

          Regards,

          Xiuping Qiu

          _______________________________________________

          Xiuping Qiu

          Huawei Technologies Co., Ltd.

          Mail to   qiuxiuping@sz.huawei.com.cn

          Visit     http://www.huawei.com.cn

          _______________________________________________
        

        


--------------E3E3C68F788CAA708BCDD5CA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 17:44:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28132
	for ; Mon, 24 Jan 2000 17:44:26 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.531A3CB0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 17:42:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6303 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 17:40:58 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.2BE4DA60@standards.nortelnetworks.com>; Mon, 24 Jan 2000 17:40:57
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id PAA17948 for
          ; Mon, 24 Jan 2000 15:42:20
          -0700 (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388CD527.E2167B15@aztek-eng.com>
Date:         Mon, 24 Jan 2000 15:41:43 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      DTMF and Signals descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Please tell me if I'm correct in assuming that there are at least
two ways for the MGC to request the MG to signal DTMF digits on a
physical termination. I also have some V13 comments related to
the signal descriptor below.

Are both of these correct for dialing '125'?

Signals {
   dg/pt {
      ind=100,         ; interdigit duration
      tl=[d1,d2,d5]   ; dtmf digits 125
   }
}
In this case how is the signal duration specified?

or

SignalList = 10 {
   SignalType=Timeout,
   Duration=250,
   dg/d1,
   dg/d2,
   dg/d5
}

V13 comments:
In 7.1.11 the last sentence of the 1st paragraph refers to
"sequential play lists". I assume that is the same as "sequential
signal lists" so it should be replaced to avoid confusion.

In the ABNF for signalListParm the preceding comments contains
the phrase "at most once duration and every signal parameter". I
understand "at most once duration" but I don't understand what is
meant to be conveyed by the rest of the phrase.

In the ABNF for signalListParm if SigSignalType=Timeout is
sigDuration required? The description of timeout in 7.1.11
implies if there is no duration the signal is played until it is
turned off. In a signal list this doesn't make sense because the
first signal in the list would be the only signal played,
wouldn't it?

Thanks for any clarifications!
Jo


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 19:45:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01097
	for ; Mon, 24 Jan 2000 19:45:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D5A1740@standards.nortelnetworks.com>; Mon, 24 Jan 2000 19:43:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6361 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 19:42:02 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.1605BB40@standards.nortelnetworks.com>; Mon, 24 Jan 2000
          19:42:02 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 24 Jan 2000 18:43:06 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 24 Jan 2000 19:42:50
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 24 Jan 2000 18:42:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF66CD.19DBB542"
Message-ID:  
Date:         Mon, 24 Jan 2000 18:42:42 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Preconditions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF66CD.19DBB542
Content-Type: text/plain;
        charset="iso-8859-1"

This issue got a brief but thorough airing in the thread "questions
regarding hook state in residential gateways", initiated by Wai-Tak Siu and
running from 19-24 November 1999.  It's my fault for not stating a
resolution to the thread.  Rather than do so immediately I'll run over the
elements of the discussion.

First: what is the problem?  In the note below, Michael says there is a
potential problem of persistent state mismatches between the MG and the MGC.
Wai-Tak's problem statements (Nov. 19 and Nov. 20) illustrated this for the
particular case of line off-hook before the MG-MGC association was fully
established.

Note the elements of this situation: there is an objective device state
which changes autonomously, outside of the control either of the MG or the
MGC.  It is possible for the MGC to make an incorrect assumption about this
initial state.  In the particular case of line off-hook, the condition is
self-correcting, at the potential cost of subscriber discontent.  The
solution preferred by Michael and Wai-Tak is that the MG be allowed to
report the actual state of the line at the time that the MGC takes control.
Some of the discussion in the thread focussed on ways to do this, whether
via a state mismatch report or via a report of the original off-hook event.
In the latter case the event might either have been preserved in a buffer or
inferred from the current line state.

There was an objection (Jon Steer, seconded by Brian Rosen) that "state" is
implementation-dependent in the first place, and that we can't just solve
this for lines without solving it for other termination types too.  I'll
just suggest that in the very specific case of lines, hook state is pretty
clear -- it's not just an artifact of the implementation.  Given that there
is a package specifically devoted to lines, I would think that we could
achieve a satisfactory solution for that one case.  This is NOT, as Michael
suggests, elementary wisdom from MGCP -- it is a special solution to a
special case.

So the obvious question after that : what about the general case?  My
experience with distributed systems in the past is that auditing is a way of
life if you want to keep the system sane.  It may take a few hours to
complete one audit cycle, but it's better than nothing.  Of course, an audit
wouldn't catch the line hook state mismatch as our protocol currently stands
-- it will only catch discrepancies between what the MGC thought the MG
executed and what the MG has actually executed.  It seems reasonable,
therefore, that we have to identify externally-driven states wherever we can
find them and make sure the related package definitions handle them
properly.

Hope this helps to frame the discussion.

> -----Original Message-----
> From: Michael Thomas [SMTP:mat@CISCO.COM]
> Sent: Saturday, January 22, 2000 3:22 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Preconditions
>
> Rosen, Brian writes:
>  > Frankly, I don't think it matters a whole heck of a lot what happens in
>  > cases
>  > like this, unless there is some possibility that the MG and the MGC
> will not
>  > sync quickly.
>
>    That's a very big "unless".
>
>  > They do in this case -- the user hangs up, and then the state
>  > is consistent, the next time he goes off hook, the right thing happens.
> If
>  > anyone
>  > can define a case that doesn't converge like this, please speak now,
>
>    A device control protocol like MEGACO is utterly
>    at the mercy of a shared view of the device's
>    state. If the MG and MGC are out of sync and the
>    MG has no way to convey that within the protocol,
>    the protocol is broken. Period. Relagating such things
>    to audits is even more broken, because MGC's in the
>    real world have about zero incentive to do what
>    amounts to device state polling -- which does
>    not scale for high fanout devices like residential gateways.
>
>  > I recommend we say "thanks for sharing"
>
>    This is a base functionality of MGCP -- the
>    only protocol which has any track record
>    thus far. Is this more Anything But MGCP
>    hubris again?
>
>    I would say that the onus is on the naysayers
>    to actually prove there does not exist any
>    unrecoverable and non self-healing state
>    mismatches. It is completely unreasonable for
>    those who would like to have a more robust
>    protocol to prove a negative.
>
>                 Mike

------_=_NextPart_001_01BF66CD.19DBB542
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Preconditions




        This issue got a =
brief but thorough airing in the thread "questions regarding hook =
state in residential gateways", initiated by Wai-Tak Siu and =
running from 19-24 November 1999.  It's my fault for not stating a =
resolution to the thread.  Rather than do so immediately I'll run =
over the elements of the discussion.
        


        First: what is the =
problem?  In the note below, Michael says there is a potential =
problem of persistent state mismatches between the MG and the =
MGC.  Wai-Tak's problem statements (Nov. 19 and Nov. 20) =
illustrated this for the particular case of line off-hook before the =
MG-MGC association was fully established.  
        


        Note the elements of =
this situation: there is an objective device state which changes =
autonomously, outside of the control either of the MG or the MGC.  =
It is possible for the MGC to make an incorrect assumption about this =
initial state.  In the particular case of line off-hook, the =
condition is self-correcting, at the potential cost of subscriber =
discontent.  The solution preferred by Michael and Wai-Tak is that =
the MG be allowed to report the actual state of the line at the time =
that the MGC takes control.  Some of the discussion in the thread =
focussed on ways to do this, whether via a state mismatch report or via =
a report of the original off-hook event.  In the latter case the =
event might either have been preserved in a buffer or inferred from the =
current line state.
        


        There was an =
objection (Jon Steer, seconded by Brian Rosen) that "state" =
is implementation-dependent in the first place, and that we can't just =
solve this for lines without solving it for other termination types =
too.  I'll just suggest that in the very specific case of lines, =
hook state is pretty clear -- it's not just an artifact of the =
implementation.  Given that there is a package specifically =
devoted to lines, I would think that we could achieve a satisfactory =
solution for that one case.  This is NOT, as Michael suggests, =
elementary wisdom from MGCP -- it is a special solution to a special =
case.
        


        So the obvious =
question after that : what about the general case?  My experience =
with distributed systems in the past is that auditing is a way of life =
if you want to keep the system sane.  It may take a few hours to =
complete one audit cycle, but it's better than nothing.  Of =
course, an audit wouldn't catch the line hook state mismatch as our =
protocol currently stands -- it will only catch discrepancies between =
what the MGC thought the MG executed and what the MG has actually =
executed.  It seems reasonable, therefore, that we have to =
identify externally-driven states wherever we can find them and make =
sure the related package definitions handle them properly.
        


        Hope this helps to =
frame the discussion.

        

          

          -----Original Message-----

          From:   Michael Thomas [SMTP:mat@CISCO.COM]

          Sent:   Saturday, January 22, 2000 3:22 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Preconditions

          


          Rosen, Brian writes:

           > Frankly, I don't think it =
matters a whole heck of a lot what happens in

           > cases

           > like this, unless there is =
some possibility that the MG and the MGC will not

           > sync quickly.

          


             That's a very big =
"unless".

          


           > They do in this case -- the =
user hangs up, and then the state

           > is consistent, the next =
time he goes off hook, the right thing happens.  If

           > anyone

           > can define a case that =
doesn't converge like this, please speak now,

          


             A device control protocol =
like MEGACO is utterly

             at the mercy of a shared =
view of the device's

             state. If the MG and MGC =
are out of sync and the

             MG has no way to convey =
that within the protocol,

             the protocol is broken. =
Period. Relagating such things

             to audits is even more =
broken, because MGC's in the

             real world have about =
zero incentive to do what

             amounts to device state =
polling -- which does

             not scale for high =
fanout devices like residential gateways.

          


           > I recommend we say =
"thanks for sharing"

          


             This is a base =
functionality of MGCP -- the

             only protocol which has =
any track record

             thus far. Is this more =
Anything But MGCP

             hubris again?

          


             I would say that the onus =
is on the naysayers

             to actually prove there =
does not exist any

             unrecoverable and non =
self-healing state

             mismatches. It is =
completely unreasonable for

             those who would like to =
have a more robust

             protocol to prove a =
negative.

          


                   &nb=
sp;      Mike

          

        


------_=_NextPart_001_01BF66CD.19DBB542--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 22:23:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03957
	for ; Mon, 24 Jan 2000 22:23:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F97C210@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:19:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6503 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 22:18:00 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7A28DD50@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:08:00
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA10593; Mon, 24 Jan
          2000 22:09:35 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA05194; Mon, 24 Jan
          2000 22:09:37 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 24 Jan 2000 22:06:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B74@whq-msgusr-02.fore.com>
Date:         Mon, 24 Jan 2000 22:09:34 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: ServiceChange
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Okay with me

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@lucent.com]
> Sent: Monday, January 24, 2000 7:06 AM
> To: Rosen, Brian
> Cc: MEGACO@standards.nortelnetworks.com
> Subject: Re: ServiceChange
>
>
> Brian, Chuong,
>
> The current text in Section 7.2.8 (first sentence of sixth paragraph
> after the numbered list of ServiceChangeMethods) reads "A
> ServiceChange
> Command specifying the "Root" for the TerminationID is a registration
> command [...]"  This does seem to be inconsistent with later sections.
>
> How about changing "A ServiceChange Command specifying the "Root" for
> the TerminationID and ServiceChangeMethod equal to Restart is a
> registration command [...]" ?
>
> John
>
>      There are really 2 methods for registration, Restart or Failover
>
>      as being the first message from MG to MGC.  Section 7.2.8 implies
>
>      only one - Restart w/ROOT.  Section 11.5 implies Failover w/ROOT.
>
>      Section 7.2.8 ServiceChange
>
>      "6. Failover - send from MG to MGC to indicate the primary MG is
> out
>
>      service and a secondary MG is taking over."
>
>      This matches section 11.4 but in section 11.5, this
> method is also
>
>      used by MG to register with Primary or Secondary MGC.
>
>      Does the text need to be cleaned or more clarification?
>
>      [BR] We should look at that.
>
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 22:23:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03959
	for ; Mon, 24 Jan 2000 22:23:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10009600@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:19:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6504 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 22:18:02 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7B57C060@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:08:02
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA10599; Mon, 24 Jan
          2000 22:09:40 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA05206; Mon, 24 Jan
          2000 22:09:43 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 24 Jan 2000 22:06:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B75@whq-msgusr-02.fore.com>
Date:         Mon, 24 Jan 2000 22:09:36 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Completion Event for signal timeout
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Does my proposal accomplish the goals?  It seems to me that it does, and
avoids a couple of problems alluded to earlier (Event Buffer).

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Monday, January 24, 2000 7:09 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Completion Event for signal timeout
>
>
> I'll second that.  If it's an event, I don't see how we can get
> granularity finer than signals descriptor level.
>
> John
>
> > Tom-PT Taylor wrote:
> >
> > If it's an optional parameter for signals it makes life a lot easier
> > -- you can say exactly which signal you want to get the report for
> > with no fuss.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Friday, January 21, 2000 5:44 PM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Completion Event for signal timeout
> >
> >      It has been suggested that we have a way to find out that a
> >      signal
> >      (or signal list) of type TIMEOUT have an event which could be
> >      triggered when the timer expired.  We can generalize this to
> >      completion of any signal.
> >
> >      I propose that we define an event in generic called sc, signal
> >      completion,
> >      which has a parameter, a list of the names of events to
> >      report completion.
> >
> >      The alternative is to add syntax to signals.  I think
> it's better
> >
> >      to make it an event - it looks like an event, acts
> like an event,
> >
> >      it is an event.
> >
> >      Brian
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 22:23:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03966
	for ; Mon, 24 Jan 2000 22:23:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1064AF00@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:19:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6505 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 22:18:07 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7E576BD0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:08:07
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA10607; Mon, 24 Jan
          2000 22:09:45 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA05216; Mon, 24 Jan
          2000 22:09:47 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 24 Jan 2000 22:06:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF66E1.37D918B4"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B76@whq-msgusr-02.fore.com>
Date:         Mon, 24 Jan 2000 22:09:42 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF66E1.37D918B4
Content-Type: text/plain;
        charset="iso-8859-1"

I think this is headed in the wrong direction.  Subtract of wildcarded
contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

It is also useful in a wildcard Audit, with or without W-.

So I think it is allowed, period.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, January 24, 2000 10:06 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Subtract Command with wildcard Termiantion Name



Your question has a couple of wider implications.  My first reaction was to
say this was an error, because in principle the MGC can always know which
context a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine the
current context of a termination if it doesn't know it already.

I think the answer has to be that we change the production auditOther to
include the context ID.

e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

Then the answer to your original question is that it is an error.

        -----Original Message-----
From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Subtract Command with wildcard Termiantion Name

        Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

        Regards
MadhuBabu


------_=_NextPart_001_01BF66E1.37D918B4
Content-Type: text/html;
        charset="iso-8859-1"




RE: Subtract Command with wildcard Termiantion Name




        I
think this is headed in the wrong direction.  Subtract of wildcarded
contextId was explicitly allowed for,
        

        among
other things, the response to a ServiceChange with mass out of service
operations pending.
        

        The
MGC must subtract all calls, and do it in a hurry.
        

         
        

        It is
also useful in a wildcard Audit, with or without W-.
        

         
        

        So I
think it is allowed, period.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Monday, January 24, 2000
  10:06 AM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Subtract Command with wildcard Termiantion Name

        
  
        Your question has a couple of wider
  implications.  My first reaction was to say this was an error, because in
  principle the MGC can always know which context a termination is in, through
  audits if necessary.  Then I checked out our audit response syntax and
  realized that the MGC cannot determine the current context of a termination if
  it doesn't know it already.
        
  
        I think the answer has to be that we
  change the production auditOther to include the context ID. 
          
        e.g. auditOther =
  EQUAL TerminationID LBRKT  CtxToken
  EQUAL ContextID  terminationAudit RBRKT 
        
  
        Then the answer to your original
  question is that it is an error. 
        
  
          
    
          -----Original Message----- 
          From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM] 
          Sent:   Sunday, January 23, 2000 11:56 PM 
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
          Subject:        Subtract Command with wildcard Termiantion Name

          
    
          Hi! 
               Here is a small query regarding the case
    where ContextID is "*" and 
          Termination
    Name is fully-specified. Does this implies that MGC intends to
    
          Subtract the specific termination from
    
          "whichever" context it appears in ? Or it is an
    error because a termination can 
          exist
    only in one context and 
          ContextID = "*"
    for a specific termination is an error ? 
          
    
          Regards 
          MadhuBabu 
        

------_=_NextPart_001_01BF66E1.37D918B4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 22:23:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03977
	for ; Mon, 24 Jan 2000 22:23:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10EA32B0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:19:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6506 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 22:18:13 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.819EA790@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:08:12
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA10621; Mon, 24 Jan
          2000 22:09:51 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA05233; Mon, 24 Jan
          2000 22:09:53 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 24 Jan 2000 22:06:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF66E1.3BC4D6B6"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B78@whq-msgusr-02.fore.com>
Date:         Mon, 24 Jan 2000 22:09:48 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Question about Protocol Version Negaotiation
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF66E1.3BC4D6B6
Content-Type: text/plain;
        charset="iso-8859-1"

In every transaction header

Brian

-----Original Message-----
From: Jo Friedman [mailto:jo@aztek-eng.com]
Sent: Monday, January 24, 2000 12:33 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Question about Protocol Version Negaotiation


I have a simple, related question. Where is the current MEGACO protocol
version identified in the spec? Seems like this is missing.

Tom-PT Taylor wrote:




At this point our only backward compatibility mechanism is the fallback to
earlier version.


You make a good point: there is no message by which the MG can reject the
fallback.  The answer, it seems to me, is that it doesn't send one -- it
simply doesn't follow up on its original message and rejects any command the
MGC tries to send it.  If it connected to the MGC (e.g. via TCP) it breaks
the connection.


        -----Original Message-----
From:   Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
Sent:   Saturday, January 22, 2000 9:51 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Question about Protocol Version Negaotiation

        Hi, All.


        In 11.3 Negotiation of Protocol Version


        1. The first ServiceChange command from MG contains a version number
.
2. MGC supports only a lower version, then the MGC sends a
ServiceChangeReply with the lower version . 3. If the MG is unable to
comply, it will reject the association, with Error 406 Version Not
Supported.


        I wonder what command will MG use in step 3 .
Will it be notify? but there is no EventDescriptor.
And is it a TransactionRequest , but it is with Error code.
IMO, error code is together with TransactionReply but not TransactionRequest
?


        And another question, I remember it says that MEGACO/H.248 will be
compatible backwards somewhere.
Then  if both MG and MGC use the lower version, why there  still exists
complying problem.


        Regards,
Xiuping Qiu
_______________________________________________


        Xiuping Qiu
Huawei Technologies Co., Ltd.
Mail to   qiuxiuping@sz.huawei.com.cn
Visit     http://www.huawei.com.cn 
_______________________________________________


------_=_NextPart_001_01BF66E1.3BC4D6B6
Content-Type: text/html;
        charset="iso-8859-1"









        In
every transaction header 
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Jo Friedman
  [mailto:jo@aztek-eng.com]
        Sent: Monday, January 24, 2000 12:33
  PM
        To: MEGACO@standards.nortelnetworks.com
        Subject: Re:
  Question about Protocol Version Negaotiation

        I have a
  simple, related question. Where is the current MEGACO protocol version
  identified in the spec? Seems like this is missing.
  
        Tom-PT Taylor wrote:
  
         
    
        At this point our only
    backward compatibility mechanism is the fallback to earlier
    version.
    
        You make a good point:
    there is no message by which the MG can reject the fallback.  The
    answer, it seems to me, is that it doesn't send one -- it simply doesn't
    follow up on its original message and rejects any command the MGC tries to
    send it.  If it connected to the MGC (e.g. via TCP) it breaks the
    connection.
    
          -----Original
      Message----- 
          From:   Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
      
          Sent:  
      Saturday, January 22, 2000 9:51
      AM 
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      
          Subject:       
      Question about Protocol Version
      Negaotiation
      
          Hi, All.
      
          In 11.3 Negotiation of Protocol
      Version
      
          1. The first ServiceChange command from
      MG contains a version number . 
          2. MGC supports only a lower version, then the MGC sends a
      ServiceChangeReply with the lower version . 3. If the MG is unable to
      comply, it will reject the association, with Error 406 Version Not
      Supported.
      
          I wonder what command will MG use in
      step 3 . 
          Will it be
      notify? but there is no EventDescriptor. 
          And is it a TransactionRequest , but it is with
      Error code. 
          IMO, error
      code is together with TransactionReply but not TransactionRequest
      ?
      
          And another question, I remember it says
      that MEGACO/H.248 will be compatible backwards somewhere.
      
          Then  if both MG and MGC use the
      lower version, why there  still exists complying
      problem.
      
          Regards, 
          Xiuping Qiu 
          _______________________________________________
      
          Xiuping Qiu 
          Huawei Technologies Co., Ltd.
      
          Mail to  
      qiuxiuping@sz.huawei.com.cn 
          Visit     http://www.huawei.com.cn
      
          _______________________________________________
        

------_=_NextPart_001_01BF66E1.3BC4D6B6--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 24 22:23:21 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03989
	for ; Mon, 24 Jan 2000 22:23:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.114E72C0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:19:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6507 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 24 Jan 2000 22:18:21 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.838E90B0@standards.nortelnetworks.com>; Mon, 24 Jan 2000 22:08:16
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA10619; Mon, 24 Jan
          2000 22:09:51 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA05232; Mon, 24 Jan
          2000 22:09:53 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 24 Jan 2000 22:06:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0B79@whq-msgusr-02.fore.com>
Date:         Mon, 24 Jan 2000 22:09:49 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: DTMF and Signals descriptor
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

See comments below

> -----Original Message-----
> From: Jo Friedman [mailto:jo@aztek-eng.com]
> Sent: Monday, January 24, 2000 5:42 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: DTMF and Signals descriptor
>
>
> Please tell me if I'm correct in assuming that there are at least
> two ways for the MGC to request the MG to signal DTMF digits on a
> physical termination. I also have some V13 comments related to
> the signal descriptor below.
>
> Are both of these correct for dialing '125'?
>
> Signals {
>    dg/pt {
>       ind=100,         ; interdigit duration
>       tl=[d1,d2,d5]   ; dtmf digits 125
>    }
> }
> In this case how is the signal duration specified?
Since the default SignalType for dtmf digits is BRief, the duration is
fixed (or provisioned) it could be overriden by using the duration parameter

to specify something else.  SignalType and Duration are available for every
signal.

>
> or
>
> SignalList = 10 {
>    SignalType=Timeout,
>    Duration=250,
>    dg/d1,
>    dg/d2,
>    dg/d5
> }
Yes

> V13 comments:
> In 7.1.11 the last sentence of the 1st paragraph refers to
> "sequential play lists". I assume that is the same as "sequential
> signal lists" so it should be replaced to avoid confusion.
Yes, we should fix this

>
> In the ABNF for signalListParm the preceding comments contains
> the phrase "at most once duration and every signal parameter". I
> understand "at most once duration" but I don't understand what is
> meant to be conveyed by the rest of the phrase.
I think it means that a parameter to a signal can only occur once per
signal instance in the list (but signal can occur more than once, and
in each case signal parameters can be included (once).

>
> In the ABNF for signalListParm if SigSignalType=Timeout is
> sigDuration required? The description of timeout in 7.1.11
> implies if there is no duration the signal is played until it is
> turned off. In a signal list this doesn't make sense because the
> first signal in the list would be the only signal played,
> wouldn't it?
I don't think we talked about this.  A normal signal has a default duration
and if not specified, that is what you use.  A signal list does not have
a default duration.  At the moment, I'd say it's an error to specify
SignalType = TimeOut and not specify Duration.

>
> Thanks for any clarifications!
> Jo
>

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 02:50:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19924
	for ; Tue, 25 Jan 2000 02:50:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9269BFC0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 2:47:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6859 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 02:47:09 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.79314C30@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          2:47:09 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA28379
          for ; Tue, 25 Jan 2000 02:48:50
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          CAA28339 for ; Tue, 25 Jan 2000
          02:48:47 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA18142; Tue,
          25 Jan 2000 08:48:24 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          IAA18083; Tue, 25 Jan 2000 08:47:58 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B29@whq-msgusr-02.fore.com>
            <388C400B.3285040F@lucent.com> <388C640B.BC1D28D8@usa.alcatel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388D54D7.8A96D7FC@lucent.com>
Date:         Tue, 25 Jan 2000 08:46:31 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I think that we have a different interpretation of the word
registration.  In my interpretation registration=restart and
failover=failover.  In your interpretation, a failover scenario contains
registration.

Why is your proposal ("A ServiceChange Command specifying the "Root" for
the TerminationID and ServiceChangeMethod equal to Restart or Failover
is a registration command by which a Media Gateway announces its
existence to the Media Gateway Controller") more clear than the existing
text ("A ServiceChange Command specifying the "Root" for the
TerminationID is a registration command by which a Media Gateway
announces its existence to the Media Gateway Controller")?

John

Chuong Nguyen wrote:
>
> For either Restart or Failover, one would still has to specify ROOT at
> the terminationID.
> Also both methods really resulted in a registration since the MGC
> receiving this ServiceChange
> can still deny the registering MG.
>
> If you want to change the text then it should be
> "A ServiceChange Command specifying the "Root" for
> the TerminationID and ServiceChangeMethod equal to Restart or Failover
> is a
> registration command [...]"
>
> Chuong
>
>
> John Segers wrote:
>
> > Brian, Chuong,
> >
> > The current text in Section 7.2.8 (first sentence of sixth paragraph
> >
> > after the numbered list of ServiceChangeMethods) reads "A
> > ServiceChange
> > Command specifying the "Root" for the TerminationID is a
> > registration
> > command [...]"  This does seem to be inconsistent with later
> > sections.
> >
> > How about changing "A ServiceChange Command specifying the "Root"
> > for
> > the TerminationID and ServiceChangeMethod equal to Restart is a
> > registration command [...]" ?
> >
> > John
> >
> >      There are really 2 methods for registration, Restart or
> > Failover
> >
> >      as being the first message from MG to MGC.  Section 7.2.8
> > implies
> >
> >      only one - Restart w/ROOT.  Section 11.5 implies Failover
> > w/ROOT.
> >
> >      Section 7.2.8 ServiceChange
> >
> >      "6. Failover - send from MG to MGC to indicate the primary MG
> > is
> > out
> >
> >      service and a secondary MG is taking over."
> >
> >      This matches section 11.4 but in section 11.5, this method is
> > also
> >
> >      used by MG to register with Primary or Secondary MGC.
> >
> >      Does the text need to be cleaned or more clarification?
> >
> >      [BR] We should look at that.
> >
> > --
> > John Segers                                  email:
> > jsegers@lucent.com
> > Lucent Technologies                                        Room HE
> > 306
> > Dept. Forward Looking Work                      phone: +31 35 687
> > 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687
> > 5954
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 03:09:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20100
	for ; Tue, 25 Jan 2000 03:09:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3B3F4460@standards.nortelnetworks.com>; Tue, 25 Jan 2000 3:06:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6886 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 03:05:08 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.FC4EE6C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          3:05:08 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA06024
          for ; Tue, 25 Jan 2000 03:06:49
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          DAA05862 for ; Tue, 25 Jan 2000
          03:06:25 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA20832; Tue,
          25 Jan 2000 09:06:02 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          JAA20512; Tue, 25 Jan 2000 09:03:31 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: "Rosen, Brian" 
References: <4FBEA8857476D311A03300204840E1CF1A0B75@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388D587B.AD120E6C@lucent.com>
Date:         Tue, 25 Jan 2000 09:02:03 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Completion Event for signal timeout
X-cc:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Brian,

I tried finding your proposal, but all I found was "I propose that we
define an event in generic called sc, signal completion, which has a
parameter, a list of the names of events to report completion." (in a
message you sent to the list last Friday).  Can you repost the proposal
you're talking about?

John

"Rosen, Brian" wrote:
>
> Does my proposal accomplish the goals?  It seems to me that it does, and
> avoids a couple of problems alluded to earlier (Event Buffer).
>
> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Monday, January 24, 2000 7:09 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Completion Event for signal timeout
> >
> >
> > I'll second that.  If it's an event, I don't see how we can get
> > granularity finer than signals descriptor level.
> >
> > John
> >
> > > Tom-PT Taylor wrote:
> > >
> > > If it's an optional parameter for signals it makes life a lot easier
> > > -- you can say exactly which signal you want to get the report for
> > > with no fuss.
> > >
> > >      -----Original Message-----
> > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> > >      Sent:   Friday, January 21, 2000 5:44 PM
> > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > >      Subject:        Completion Event for signal timeout
> > >
> > >      It has been suggested that we have a way to find out that a
> > >      signal
> > >      (or signal list) of type TIMEOUT have an event which could be
> > >      triggered when the timer expired.  We can generalize this to
> > >      completion of any signal.
> > >
> > >      I propose that we define an event in generic called sc, signal
> > >      completion,
> > >      which has a parameter, a list of the names of events to
> > >      report completion.
> > >
> > >      The alternative is to add syntax to signals.  I think
> > it's better
> > >
> > >      to make it an event - it looks like an event, acts
> > like an event,
> > >
> > >      it is an event.
> > >
> > >      Brian
> >
> > --
> > John Segers                                  email: jsegers@lucent.com
> > Lucent Technologies                                        Room HE 306
> > Dept. Forward Looking Work                      phone: +31 35 687 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 03:20:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20170
	for ; Tue, 25 Jan 2000 03:20:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5E9F730@standards.nortelnetworks.com>; Tue, 25 Jan 2000 3:17:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6912 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 03:15:56 -0500
Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7E7D82E0@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          3:15:56 -0500
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA26436
          for ; Tue, 25 Jan 2000 03:17:37
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          DAA26428 for ; Tue, 25 Jan 2000
          03:17:36 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA21992; Tue,
          25 Jan 2000 09:17:35 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          JAA21936; Tue, 25 Jan 2000 09:17:09 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B79@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388D5BAE.F78DE1A9@lucent.com>
Date:         Tue, 25 Jan 2000 09:15:42 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: DTMF and Signals descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Jo, Brian,

I changed the occurrence of "sequential play list" to "sequential signal
list".

It doesn't make sense to me to define the duration of a seq. signal
list. So in the paragraph on sequential signal lists, I propose to add
the following sentence: "The duration of a sequential signal list with
type timeout is equal to the sum of the durations of the signals it
contains."

John

"Rosen, Brian" wrote:
>
> See comments below
>
> > -----Original Message-----
> > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > Sent: Monday, January 24, 2000 5:42 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: DTMF and Signals descriptor
> >
> >
> > Please tell me if I'm correct in assuming that there are at least
> > two ways for the MGC to request the MG to signal DTMF digits on a
> > physical termination. I also have some V13 comments related to
> > the signal descriptor below.
> >
> > Are both of these correct for dialing '125'?
> >
> > Signals {
> >    dg/pt {
> >       ind=100,         ; interdigit duration
> >       tl=[d1,d2,d5]   ; dtmf digits 125
> >    }
> > }
> > In this case how is the signal duration specified?
> Since the default SignalType for dtmf digits is BRief, the duration is
> fixed (or provisioned) it could be overriden by using the duration parameter
>
> to specify something else.  SignalType and Duration are available for every
> signal.
>
> >
> > or
> >
> > SignalList = 10 {
> >    SignalType=Timeout,
> >    Duration=250,
> >    dg/d1,
> >    dg/d2,
> >    dg/d5
> > }
> Yes
>
> > V13 comments:
> > In 7.1.11 the last sentence of the 1st paragraph refers to
> > "sequential play lists". I assume that is the same as "sequential
> > signal lists" so it should be replaced to avoid confusion.
> Yes, we should fix this
>
> >
> > In the ABNF for signalListParm the preceding comments contains
> > the phrase "at most once duration and every signal parameter". I
> > understand "at most once duration" but I don't understand what is
> > meant to be conveyed by the rest of the phrase.
> I think it means that a parameter to a signal can only occur once per
> signal instance in the list (but signal can occur more than once, and
> in each case signal parameters can be included (once).
>
> >
> > In the ABNF for signalListParm if SigSignalType=Timeout is
> > sigDuration required? The description of timeout in 7.1.11
> > implies if there is no duration the signal is played until it is
> > turned off. In a signal list this doesn't make sense because the
> > first signal in the list would be the only signal played,
> > wouldn't it?
> I don't think we talked about this.  A normal signal has a default duration
> and if not specified, that is what you use.  A signal list does not have
> a default duration.  At the moment, I'd say it's an error to specify
> SignalType = TimeOut and not specify Duration.
>
> >
> > Thanks for any clarifications!
> > Jo
> >
>
> Brian

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 05:35:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21020
	for ; Tue, 25 Jan 2000 05:35:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5703C40@standards.nortelnetworks.com>; Tue, 25 Jan 2000 5:33:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6976 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 05:31:33 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0AF9F530@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          5:21:33 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          LAA07215; Tue, 25 Jan 2000 11:04:59 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id LAA04652;
          Tue, 25 Jan 2000 11:04:59 +0100
Received: from ericsson.com (kipe141.eraj.ericsson.se [147.214.68.141]) by
          elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id
          LAA12408; Tue, 25 Jan 2000 11:04:58 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388D7549.4289BB5C@ericsson.com>
Date:         Tue, 25 Jan 2000 11:04:57 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Completion Event for signal timeout
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Tom,

I agree with this. I think it makes sense to be able to say this for
each signal.

Cheers, Christian

Tom-PT Taylor wrote:
>
> If it's an optional parameter for signals it makes life a lot easier
> -- you can say exactly which signal you want to get the report for
> with no fuss.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Friday, January 21, 2000 5:44 PM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Completion Event for signal timeout
>
>      It has been suggested that we have a way to find out that a
>      signal
>      (or signal list) of type TIMEOUT have an event which could be
>      triggered when the timer expired.  We can generalize this to
>      completion of any signal.
>
>      I propose that we define an event in generic called sc, signal
>      completion,
>      which has a parameter, a list of the names of events to
>      report completion.
>
>      The alternative is to add syntax to signals.  I think it's better
>
>      to make it an event - it looks like an event, acts like an event,
>
>      it is an event.
>
>      Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 06:39:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21536
	for ; Tue, 25 Jan 2000 06:39:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.97BA5280@standards.nortelnetworks.com>; Tue, 25 Jan 2000 6:37:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7005 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 06:36:16 -0500
Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.79B62610@standards.nortelnetworks.com>; Tue, 25 Jan 2000 6:36:13
          -0500
Received: from ficon-tech.com (vikasb.india.ficon-tech.com [172.25.1.109]) by
          ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA24834 for
          ; Tue, 25 Jan 2000 17:02:12
          +0530 (IST) (envelope-from skgupta@ficon-tech.com)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388D8C0F.9B266F01@ficon-tech.com>
Date:         Tue, 25 Jan 2000 17:12:07 +0530
Reply-To: "Sanjay Kr. Gupta" 
Sender: "Media Gateway Control (megaco)"
              
From: "Sanjay Kr. Gupta" 
Organization: Ficon Technology
Subject:      regarding multiple Error Descriptors in command replies.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Brian / John,

    In ABNF of v13, Error Descriptor has been moved to the production
terminationAudit, this would imply that there can be multiple
ErrorDescriptors in each ammsReply/auditReply (in fact it has been
mentioned in the comments also).

When can multiple Error descriptors be sent in the reply to Add, Move,
Modify, Subtract & Audit commands ?


Regards,
Sanjay Kr. Gupta
Ficon Technology
e-mail : mailto:skgupta@ficon-tech.com
web: http://www.ficon-tech.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 07:02:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21689
	for ; Tue, 25 Jan 2000 07:02:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF5EFBC0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 7:00:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7024 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 06:58:59 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.41E1EF10@standards.nortelnetworks.com>; Tue, 25 Jan 2000 6:48:59
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id GAA27670; Tue, 25 Jan
          2000 06:50:38 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id GAA09923; Tue, 25 Jan
          2000 06:50:30 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Tue, 25 Jan 2000 06:47:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20881F@whq-msgusr-02.fore.com>
Date:         Tue, 25 Jan 2000 06:50:21 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Completion Event for signal timeout
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sorry, seems like it got stuck in my outbox!

It's messy to have event enables in two places.  As an example of the
problems, what
do you do with the Event Buffer?

The syntax I imagine is:
..Signal(cs/rt{SignalType=TimeOut, Duration=4000}},Events{g/st{cs/rt}}

That's pretty low fuss, says exactly which signals, etc.

Brian


> -----Original Message-----
> From: John Segers [mailto:jsegers@lucent.com]
> Sent: Tuesday, January 25, 2000 3:02 AM
> To: MEGACO@standards.nortelnetworks.com
> Cc: Rosen, Brian
> Subject: Re: Completion Event for signal timeout
>
>
> Brian,
>
> I tried finding your proposal, but all I found was "I propose that we
> define an event in generic called sc, signal completion, which has a
> parameter, a list of the names of events to report completion." (in a
> message you sent to the list last Friday).  Can you repost
> the proposal
> you're talking about?
>
> John
>
> "Rosen, Brian" wrote:
> >
> > Does my proposal accomplish the goals?  It seems to me that
> it does, and
> > avoids a couple of problems alluded to earlier (Event Buffer).
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: John Segers [mailto:jsegers@LUCENT.COM]
> > > Sent: Monday, January 24, 2000 7:09 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: Completion Event for signal timeout
> > >
> > >
> > > I'll second that.  If it's an event, I don't see how we can get
> > > granularity finer than signals descriptor level.
> > >
> > > John
> > >
> > > > Tom-PT Taylor wrote:
> > > >
> > > > If it's an optional parameter for signals it makes life
> a lot easier
> > > > -- you can say exactly which signal you want to get the
> report for
> > > > with no fuss.
> > > >
> > > >      -----Original Message-----
> > > >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> > > >      Sent:   Friday, January 21, 2000 5:44 PM
> > > >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > >      Subject:        Completion Event for signal timeout
> > > >
> > > >      It has been suggested that we have a way to find out that a
> > > >      signal
> > > >      (or signal list) of type TIMEOUT have an event
> which could be
> > > >      triggered when the timer expired.  We can
> generalize this to
> > > >      completion of any signal.
> > > >
> > > >      I propose that we define an event in generic
> called sc, signal
> > > >      completion,
> > > >      which has a parameter, a list of the names of events to
> > > >      report completion.
> > > >
> > > >      The alternative is to add syntax to signals.  I think
> > > it's better
> > > >
> > > >      to make it an event - it looks like an event, acts
> > > like an event,
> > > >
> > > >      it is an event.
> > > >
> > > >      Brian
> > >
> > > --
> > > John Segers                                  email:
> jsegers@lucent.com
> > > Lucent Technologies
>  Room HE 306
> > > Dept. Forward Looking Work                      phone:
> +31 35 687 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax:
> +31 35 687 5954
> > >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 07:10:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21806
	for ; Tue, 25 Jan 2000 07:10:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EEEF7810@standards.nortelnetworks.com>; Tue, 25 Jan 2000 7:08:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7027 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 07:07:30 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.72209770@standards.nortelnetworks.com>; Tue, 25 Jan 2000 6:57:29
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id GAA27919; Tue, 25 Jan
          2000 06:59:10 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id GAA10522; Tue, 25 Jan
          2000 06:59:11 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Tue, 25 Jan 2000 06:56:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208820@whq-msgusr-02.fore.com>
Date:         Tue, 25 Jan 2000 06:59:04 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: DTMF and Signals descriptor
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This doesn't make sense to me; why would you be able to change the
SignalType but not the duration.  If you want signal lists to not have
duration, they should not have signal type.  That is okay with me, the
signal type is then always defined by the last signal.

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Tuesday, January 25, 2000 3:16 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: DTMF and Signals descriptor
>
>
> Jo, Brian,
>
> I changed the occurrence of "sequential play list" to
> "sequential signal
> list".
>
> It doesn't make sense to me to define the duration of a seq. signal
> list. So in the paragraph on sequential signal lists, I propose to add
> the following sentence: "The duration of a sequential signal list with
> type timeout is equal to the sum of the durations of the signals it
> contains."
>
> John
>
> "Rosen, Brian" wrote:
> >
> > See comments below
> >
> > > -----Original Message-----
> > > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > > Sent: Monday, January 24, 2000 5:42 PM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: DTMF and Signals descriptor
> > >
> > >
> > > Please tell me if I'm correct in assuming that there are at least
> > > two ways for the MGC to request the MG to signal DTMF digits on a
> > > physical termination. I also have some V13 comments related to
> > > the signal descriptor below.
> > >
> > > Are both of these correct for dialing '125'?
> > >
> > > Signals {
> > >    dg/pt {
> > >       ind=100,         ; interdigit duration
> > >       tl=[d1,d2,d5]   ; dtmf digits 125
> > >    }
> > > }
> > > In this case how is the signal duration specified?
> > Since the default SignalType for dtmf digits is BRief, the
> duration is
> > fixed (or provisioned) it could be overriden by using the
> duration parameter
> >
> > to specify something else.  SignalType and Duration are
> available for every
> > signal.
> >
> > >
> > > or
> > >
> > > SignalList = 10 {
> > >    SignalType=Timeout,
> > >    Duration=250,
> > >    dg/d1,
> > >    dg/d2,
> > >    dg/d5
> > > }
> > Yes
> >
> > > V13 comments:
> > > In 7.1.11 the last sentence of the 1st paragraph refers to
> > > "sequential play lists". I assume that is the same as "sequential
> > > signal lists" so it should be replaced to avoid confusion.
> > Yes, we should fix this
> >
> > >
> > > In the ABNF for signalListParm the preceding comments contains
> > > the phrase "at most once duration and every signal parameter". I
> > > understand "at most once duration" but I don't understand what is
> > > meant to be conveyed by the rest of the phrase.
> > I think it means that a parameter to a signal can only
> occur once per
> > signal instance in the list (but signal can occur more than
> once, and
> > in each case signal parameters can be included (once).
> >
> > >
> > > In the ABNF for signalListParm if SigSignalType=Timeout is
> > > sigDuration required? The description of timeout in 7.1.11
> > > implies if there is no duration the signal is played until it is
> > > turned off. In a signal list this doesn't make sense because the
> > > first signal in the list would be the only signal played,
> > > wouldn't it?
> > I don't think we talked about this.  A normal signal has a
> default duration
> > and if not specified, that is what you use.  A signal list
> does not have
> > a default duration.  At the moment, I'd say it's an error to specify
> > SignalType = TimeOut and not specify Duration.
> >
> > >
> > > Thanks for any clarifications!
> > > Jo
> > >
> >
> > Brian
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 08:25:33 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24561
	for ; Tue, 25 Jan 2000 08:25:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EC2A8F0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:23:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7180 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 08:22:17 -0500
Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4A40A6D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          8:22:16 -0500
Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA12755
          for ; Tue, 25 Jan 2000 08:23:58
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          IAA12734 for ; Tue, 25 Jan 2000
          08:23:56 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA05911; Tue,
          25 Jan 2000 14:23:34 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          OAA05859; Tue, 25 Jan 2000 14:23:14 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-To: "'MEGACO@standards.nortelnetworks.com'"
             
References: <4FBEA8857476D311A03300204840E1CF208820@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388DA36A.3FDA0169@lucent.com>
Date:         Tue, 25 Jan 2000 14:21:46 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: DTMF and Signals descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
>
> This doesn't make sense to me; why would you be able to change the
> SignalType but not the duration.  If you want signal lists to not have
> duration, they should not have signal type.  That is okay with me, the
> signal type is then always defined by the last signal.

Not by the last signal.  It's a little more complicated:
- only the last in the sequence can be on/off.  If so, the type of the
list is on/off;
- if the last in the sequence is not on/off, and there is an element in
the sequence with type timout, the type of the list is timeout;
- if all elements of the sequence are type brief, then the list is type
brief.

John

> Brian
>
> > -----Original Message-----
> > From: John Segers [mailto:jsegers@LUCENT.COM]
> > Sent: Tuesday, January 25, 2000 3:16 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: DTMF and Signals descriptor
> >
> >
> > Jo, Brian,
> >
> > I changed the occurrence of "sequential play list" to
> > "sequential signal
> > list".
> >
> > It doesn't make sense to me to define the duration of a seq. signal
> > list. So in the paragraph on sequential signal lists, I propose to add
> > the following sentence: "The duration of a sequential signal list with
> > type timeout is equal to the sum of the durations of the signals it
> > contains."
> >
> > John
> >
> > "Rosen, Brian" wrote:
> > >
> > > See comments below
> > >
> > > > -----Original Message-----
> > > > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > > > Sent: Monday, January 24, 2000 5:42 PM
> > > > To: MEGACO@standards.nortelnetworks.com
> > > > Subject: DTMF and Signals descriptor
> > > >
> > > >
> > > > Please tell me if I'm correct in assuming that there are at least
> > > > two ways for the MGC to request the MG to signal DTMF digits on a
> > > > physical termination. I also have some V13 comments related to
> > > > the signal descriptor below.
> > > >
> > > > Are both of these correct for dialing '125'?
> > > >
> > > > Signals {
> > > >    dg/pt {
> > > >       ind=100,         ; interdigit duration
> > > >       tl=[d1,d2,d5]   ; dtmf digits 125
> > > >    }
> > > > }
> > > > In this case how is the signal duration specified?
> > > Since the default SignalType for dtmf digits is BRief, the
> > duration is
> > > fixed (or provisioned) it could be overriden by using the
> > duration parameter
> > >
> > > to specify something else.  SignalType and Duration are
> > available for every
> > > signal.
> > >
> > > >
> > > > or
> > > >
> > > > SignalList = 10 {
> > > >    SignalType=Timeout,
> > > >    Duration=250,
> > > >    dg/d1,
> > > >    dg/d2,
> > > >    dg/d5
> > > > }
> > > Yes
> > >
> > > > V13 comments:
> > > > In 7.1.11 the last sentence of the 1st paragraph refers to
> > > > "sequential play lists". I assume that is the same as "sequential
> > > > signal lists" so it should be replaced to avoid confusion.
> > > Yes, we should fix this
> > >
> > > >
> > > > In the ABNF for signalListParm the preceding comments contains
> > > > the phrase "at most once duration and every signal parameter". I
> > > > understand "at most once duration" but I don't understand what is
> > > > meant to be conveyed by the rest of the phrase.
> > > I think it means that a parameter to a signal can only
> > occur once per
> > > signal instance in the list (but signal can occur more than
> > once, and
> > > in each case signal parameters can be included (once).
> > >
> > > >
> > > > In the ABNF for signalListParm if SigSignalType=Timeout is
> > > > sigDuration required? The description of timeout in 7.1.11
> > > > implies if there is no duration the signal is played until it is
> > > > turned off. In a signal list this doesn't make sense because the
> > > > first signal in the list would be the only signal played,
> > > > wouldn't it?
> > > I don't think we talked about this.  A normal signal has a
> > default duration
> > > and if not specified, that is what you use.  A signal list
> > does not have
> > > a default duration.  At the moment, I'd say it's an error to specify
> > > SignalType = TimeOut and not specify Duration.
> > >
> > > >
> > > > Thanks for any clarifications!
> > > > Jo
> > > >
> > >
> > > Brian
> >
> > --
> > John Segers                                  email: jsegers@lucent.com
> > Lucent Technologies                                        Room HE 306
> > Dept. Forward Looking Work                      phone: +31 35 687 4724
> > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 08:40:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25325
	for ; Tue, 25 Jan 2000 08:40:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88A55450@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:38:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7205 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 08:36:36 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4AC99B00@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          8:36:36 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 25 Jan 2000 07:37:46 -0600
Received: from zrchb213.us.nortel.com by zmers013; Tue, 25 Jan 2000 08:37:26
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Tue, 25 Jan 2000 07:37:23 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6739.4F59878C"
Message-ID:  
Date:         Tue, 25 Jan 2000 07:37:17 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6739.4F59878C
Content-Type: text/plain

OK, this is the second comment I've had to this effect -- the other was
received privately.  The one question is whether we want a way to find out
what context a termination is in without subtracting it to find out, in
which case the audit response syntax I suggested might be considered.
Silence means we don't need this additional functiuonality.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Monday, January 24, 2000 10:10 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Subtract Command with wildcard Termination Name
>
> I think this is headed in the wrong direction.  Subtract of wildcarded
> contextId was explicitly allowed for,
> among other things, the response to a ServiceChange with mass out of
> service operations pending.
> The MGC must subtract all calls, and do it in a hurry.
>
> It is also useful in a wildcard Audit, with or without W-.
>
> So I think it is allowed, period.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Monday, January 24, 2000 10:06 AM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Subtract Command with wildcard Termiantion Name
>
>
>
>       Your question has a couple of wider implications.  My first reaction
> was to say this was an error, because in principle the MGC can always know
> which context a termination is in, through audits if necessary.  Then I
> checked out our audit response syntax and realized that the MGC cannot
> determine the current context of a termination if it doesn't know it
> already.
>
>       I think the answer has to be that we change the production
> auditOther to include the context ID.
>
>       e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
> ContextID  terminationAudit RBRKT
>
>       Then the answer to your original question is that it is an error.
>
>               -----Original Message-----
>       From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>       Sent:   Sunday, January 23, 2000 11:56 PM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Subtract Command with wildcard Termiantion Name
>
>               Hi!
>            Here is a small query regarding the case where ContextID is "*"
> and
>       Termination Name is fully-specified. Does this implies that MGC
> intends to
>       Subtract the specific termination from
>       "whichever" context it appears in ? Or it is an error because a
> termination can
>       exist only in one context and
>       ContextID = "*" for a specific termination is an error ?
>
>               Regards
>       MadhuBabu
>

------_=_NextPart_001_01BF6739.4F59878C
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Subtract Command with wildcard Termination Name




        OK, this is the =
second comment I've had to this effect -- the other was received =
privately.  The one question is whether we want a way to find out =
what context a termination is in without subtracting it to find out, in =
which case the audit response syntax I suggested might be =
considered.  Silence means we don't need this additional =
functiuonality.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Monday, January 24, 2000 10:10 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Subtract Command with wildcard =
Termination Name

          


          I think this is =
headed in the wrong direction.=A0 Subtract of wildcarded contextId was =
explicitly allowed for,

          among other things, =
the response to a ServiceChange with mass out of service operations =
pending.

          The MGC must =
subtract all calls, and do it in a hurry.

          =A0

          It is also useful =
in a wildcard Audit, with or without W-.

          =A0

          So I think it is =
allowed, period.

          =A0

          Brian

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Monday, January 24, 2000 10:06 AM
            
            To: MEGACO@standards.nortelnetworks.com
            
            Subject: Re: Subtract Command with wildcard =
Termiantion Name
            

            
            

            


            Your question has a =
couple of wider implications.=A0 My first reaction was to say this was =
an error, because in principle the MGC can always know which context a =
termination is in, through audits if necessary.=A0 Then I checked out =
our audit response syntax and realized that the MGC cannot determine =
the current context of a termination if it doesn't know it =
already.
            


            I think the answer =
has to be that we change the production auditOther to include the =
context ID.
            
            =A0
            
e.g. auditOther =
=3D EQUAL TerminationID LBRKT=A0 CtxToken EQUAL =
ContextID=A0 terminationAudit RBRKT 

            


            Then the answer to =
your original question is that it is an error. 

            


                    -----Original Message-----
            
            From:=A0=A0 Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]
            
            Sent:=A0=A0 Sunday, January =
23, 2000 11:56 PM
            
            To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 Subtract Command =
with wildcard Termiantion Name 

            


                    Hi!
            
            =A0=A0=A0=A0 Here is a small query =
regarding the case where ContextID is "*" and
            
            Termination Name is =
fully-specified. Does this implies that MGC intends to
            
            Subtract the specific termination =
from
            
            "whichever" context it =
appears in ? Or it is an error because a termination can
            
            exist only in one context =
and
            
            ContextID =3D "*" for a =
specific termination is an error ? 

            


                    Regards
            
            MadhuBabu 

            

        


------_=_NextPart_001_01BF6739.4F59878C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 08:46:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25695
	for ; Tue, 25 Jan 2000 08:46:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19456860@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:42:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7234 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 08:41:54 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.060546D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:41:50
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id TAA14344 for
          ; Tue, 25 Jan 2000 19:41:51
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256871.004AD613 ; Tue, 25 Jan 2000 19:07:24 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256871.004AD5FF.00@sandesh.hss.hns.com>
Date:         Tue, 25 Jan 2000 19:10:47 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Error code to indicate Termination Out-of-service.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HI
     In Section 7.3 There is no error code indicating that the specified
Termination
is out of service. Does the error code 503 "Service  Unavailable"
intended for
 this purpose.

regards
Sachin Mittal.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 08:56:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26329
	for ; Tue, 25 Jan 2000 08:56:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C8C7DE70@standards.nortelnetworks.com>; Tue, 25 Jan 2000 8:54:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7286 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 08:52:28 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.82217940@standards.nortelnetworks.com>; Tue, 25 Jan 2000
          8:52:28 -0500
Received: from zmers013 by smtprch1.nortel.com; Tue, 25 Jan 2000 07:52:06 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Tue, 25
          Jan 2000 08:51:34 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Tue, 25 Jan 2000 08:51:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF673B.3ACD81C2"
Message-ID:  
Date:         Tue, 25 Jan 2000 08:51:04 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Preconditions
X-To:         Brian Rosen ,
              "John Segers (E-mail)" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF673B.3ACD81C2
Content-Type: text/plain;
        charset="iso-8859-1"

For some reason the two E-mails I've sent on this topic have been lost.
Anyway, the topic was dealt with in the thread
"questions regarding hook state in residential gateways", running 19-24 Nov
1999.
I am guilty of not drawing a conclusion from that thread.

I think the particular problem of pre-startup line off-hook has the
potential to baffle subscribers depending on their expectations.  I remember
years ago hearing of a case where dial tone in a particular Latin American
city could take up to 20 minutes to follow off-hook.  Offices had people
whose sole job was to wait for that dial tone and pass the phone over to the
caller when it came.  The moral of this is that if people expect to
eventually hear a tone, they will leave the phone off-hook.

Because this particular case can be addressed by a specific package
(Analogue Line Supervision), I suggest we add appropriate behaviour to that
package, as follows:
(1) This behaviour applies only upon reestablishment of MGC control over the
specific termination concerned or the MG as a whole.
(2) If the MGC requests monitoring for an off-hook event and the line is
already off-hook, the MG shall report occurrence of an off-hook event.
(3) If the MGC requests monitoring for an on-hook event and the line is
already on-hook, the MG shall report occurrence of an on-hook.

> -----Original Message-----
> From: Blatherwick, Peter [CAR:AT14:EXCH]
> Sent: Monday, January 24, 2000 11:05 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Preconditions
>
> My 0.02...
>
> First, we must avoid application dependencies in the protocol itself.
> Therefore setting pre-conditions as part of the base protocol, especially
> if they are aimed at particular events or signals, is not a good idea
> IMHO.  I think anything along these lines should be solved in package
> definitions since they are at least concerned with application level
> information exchange.  I don't think anyone is asking for anything other
> than careful package definition, but thought I should say this anyway.
>
> However, I do see the "invisible state transition problem" as potentially
> serious in at least some cases.  I think the best way to solve this in
> general is to define, in the affected packages, the detection event as
> "detects transition to or already in the requested state".  This would
> detect the edge OR if the state already exists.  (I'm pretty sure this is
> old ground, but darned if I can find the old thread right now.)
>
> -- Peter
>
>       -----Original Message-----
> From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent:   23 Jan, 2000 18:57
> To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:        Re: Preconditions
>
>       Let's be careful.  I believe all of these items are defined
> in packages.  I don't think there is anything like this in
> the base package.  In general, we have talked about defining
> events such as hook state as "edge detect", rather than state
> detect.  Would it solve the problem to make such events, in
> the packages, explicitly defined as change-of-state detected.
> Something like "detects the transition...".
>
>       Brian
>
>       > -----Original Message-----
> > From: Michael Thomas [ ]
> > Sent: Saturday, January 22, 2000 3:22 PM
> > To: Rosen, Brian
> > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Preconditions
> >
> >
> >
> >
> >
> > Rosen, Brian writes:
> >  > Frankly, I don't think it matters a whole heck of a lot
> > what happens in
> >  > cases
> >  > like this, unless there is some possibility that the MG
> > and the MGC will not
> >  > sync quickly.
> >
> >    That's a very big "unless".
> >
> >  > They do in this case -- the user hangs up, and then the state
> >  > is consistent, the next time he goes off hook, the right
> > thing happens.  If
> >  > anyone
> >  > can define a case that doesn't converge like this, please
> > speak now,
> >
> >    A device control protocol like MEGACO is utterly
> >    at the mercy of a shared view of the device's
> >    state. If the MG and MGC are out of sync and the
> >    MG has no way to convey that within the protocol,
> >    the protocol is broken. Period. Relagating such things
> >    to audits is even more broken, because MGC's in the
> >    real world have about zero incentive to do what
> >    amounts to device state polling -- which does
> >    not scale for high fanout devices like residential gateways.
> >
> >  > I recommend we say "thanks for sharing"
> >
> >    This is a base functionality of MGCP -- the
> >    only protocol which has any track record
> >    thus far. Is this more Anything But MGCP
> >    hubris again?
> >
> >    I would say that the onus is on the naysayers
> >    to actually prove there does not exist any
> >    unrecoverable and non self-healing state
> >    mismatches. It is completely unreasonable for
> >    those who would like to have a more robust
> >    protocol to prove a negative.
> >
> >               Mike
> >
>

------_=_NextPart_001_01BF673B.3ACD81C2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Preconditions




        For some reason the =
two E-mails I've sent on this topic have been lost.  Anyway, the =
topic was dealt with in the thread

        "questions =
regarding hook state in residential gateways", running 19-24 Nov =
1999.

        I am guilty of not =
drawing a conclusion from that thread.

        


        I think the =
particular problem of pre-startup line off-hook has the potential to =
baffle subscribers depending on their expectations.  I remember =
years ago hearing of a case where dial tone in a particular Latin =
American city could take up to 20 minutes to follow off-hook.  =
Offices had people whose sole job was to wait for that dial tone and =
pass the phone over to the caller when it came.  The moral of this =
is that if people expect to eventually hear a tone, they will leave the =
phone off-hook.
        


        Because this =
particular case can be addressed by a specific package (Analogue Line =
Supervision), I suggest we add appropriate behaviour to that package, =
as follows:
        


        (1) This behaviour =
applies only upon reestablishment of MGC control over the specific =
termination concerned or the MG as a whole.
        


        (2) If the MGC =
requests monitoring for an off-hook event and the line is already =
off-hook, the MG shall report occurrence of an off-hook =
event.
        


        (3) If the MGC =
requests monitoring for an on-hook event and the line is already =
on-hook, the MG shall report occurrence of an on-hook.
        

          

          -----Original Message-----

          From:   Blatherwick, Peter [CAR:AT14:EXCH] 

          Sent:   Monday, January 24, 2000 11:05 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Preconditions

          


          My =
0.02... 

          


          First, we must avoid =
application dependencies in the protocol itself.=A0 Therefore setting =
pre-conditions as part of the base protocol, especially if they are =
aimed at particular events or signals, is not a good idea IMHO.=A0 I =
think anything along these lines should be solved in package =
definitions since they are at least concerned with application level =
information exchange.=A0 I don't think anyone is asking for anything =
other than careful package definition, but thought I should say this =
anyway.=A0 
          


          However, I do see =
the "invisible state transition problem" as potentially =
serious in at least some cases.=A0 I think the best way to solve this =
in general is to define, in the affected packages, the detection event =
as "detects transition to or already in the requested =
state".=A0 This would detect the edge OR if the state already =
exists.=A0 (I'm pretty sure this is old ground, but darned if I can =
find the old thread right now.)=A0 
          


          -- Peter 

          


                  -----Original Message-----
          
          From:=A0=A0 Rosen, Brian [SMTP:brosen@FORE.COM]
          
          Sent:=A0=A0 23 Jan, 2000 18:57
          
          To:=A0=A0=A0=A0 =
MEGACO@STANDARDS.NORTELNETWORKS.COM
          
          Subject:=A0=A0=A0=A0=A0=A0=A0 Re: =
Preconditions 

          


                  Let's be careful.=A0 I believe all of these items are =
defined
          
          in packages.=A0 I don't think =
there is anything like this in
          
          the base package.=A0 In general, =
we have talked about defining
          
          events such as hook state as =
"edge detect", rather than state
          
          detect.=A0 Would it solve the =
problem to make such events, in
          
          the packages, explicitly defined =
as change-of-state detected.
          
          Something like "detects the =
transition...". 

          


                  Brian 

          


                  > -----Original Message-----
          
          > From: Michael Thomas =
[ =
<mailto:mat@cisco.com>]
          
          > Sent: Saturday, January 22, =
2000 3:22 PM
          
          > To: Rosen, Brian
          
          > Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM
          
          > Subject: =
Preconditions
          
          >
          
          >
          
          >
          
          >
          
          >
          
          > Rosen, Brian =
writes:
          
          >=A0 > Frankly, I don't =
think it matters a whole heck of a lot
          
          > what happens in
          
          >=A0 > cases
          
          >=A0 > like this, unless =
there is some possibility that the MG
          
          > and the MGC will =
not
          
          >=A0 > sync =
quickly.
          
          >
          
          >=A0=A0=A0 That's a very big =
"unless".
          
          >
          
          >=A0 > They do in this case =
-- the user hangs up, and then the state
          
          >=A0 > is consistent, the =
next time he goes off hook, the right
          
          > thing happens.=A0 =
If
          
          >=A0 > anyone
          
          >=A0 > can define a case =
that doesn't converge like this, please
          
          > speak now,
          
          >
          
          >=A0=A0=A0 A device control =
protocol like MEGACO is utterly
          
          >=A0=A0=A0 at the mercy of a =
shared view of the device's
          
          >=A0=A0=A0 state. If the MG and =
MGC are out of sync and the
          
          >=A0=A0=A0 MG has no way to =
convey that within the protocol,
          
          >=A0=A0=A0 the protocol is =
broken. Period. Relagating such things
          
          >=A0=A0=A0 to audits is even =
more broken, because MGC's in the
          
          >=A0=A0=A0 real world have =
about zero incentive to do what
          
          >=A0=A0=A0 amounts to device =
state polling -- which does
          
          >=A0=A0=A0 not scale for high =
fanout devices like residential gateways.
          
          >
          
          >=A0 > I recommend we say =
"thanks for sharing"
          
          >
          
          >=A0=A0=A0 This is a base =
functionality of MGCP -- the
          
          >=A0=A0=A0 only protocol which =
has any track record
          
          >=A0=A0=A0 thus far. Is this =
more Anything But MGCP
          
          >=A0=A0=A0 hubris =
again?
          
          >
          
          >=A0=A0=A0 I would say that the =
onus is on the naysayers
          
          >=A0=A0=A0 to actually prove =
there does not exist any
          
          >=A0=A0=A0 unrecoverable and =
non self-healing state
          
          >=A0=A0=A0 mismatches. It is =
completely unreasonable for
          
          >=A0=A0=A0 those who would like =
to have a more robust
          
          >=A0=A0=A0 protocol to prove a =
negative.
          
          >
          
          >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Mike
          
          > =


          

        


------_=_NextPart_001_01BF673B.3ACD81C2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 09:05:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26852
	for ; Tue, 25 Jan 2000 09:05:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0BADEAD0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 9:03:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7305 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 09:01:39 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C775C680@standards.nortelnetworks.com>; Tue, 25 Jan 2000 9:01:34
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA15674 for
          ; Tue, 25 Jan 2000 20:01:35
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256871.004CA48C ; Tue, 25 Jan 2000 19:27:08 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256871.004CA46E.00@sandesh.hss.hns.com>
Date:         Tue, 25 Jan 2000 19:30:30 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Annex B.1 says that "The CHOOSE TerminationID $ may be used to signal to the MG
that it has to create an
ephemeral Termination or select an idle physical Termination".
How can MG determine when to create an ephemeral termination and when to choose
idle physical termination.??
What is the logic behind this decision making?

regards
-Sachin Mittal


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 09:51:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28896
	for ; Tue, 25 Jan 2000 09:51:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B056E20@standards.nortelnetworks.com>; Tue, 25 Jan 2000 9:49:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7342 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 09:48:32 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.F0C3B650@standards.nortelnetworks.com>;
          Tue, 25 Jan 2000 9:38:31 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id IAA08300
          for ; Tue, 25 Jan 2000 08:39:34
          -0600 (CST)
Received: from relay2.dsccc.com(10.17.102.19) by fw3 via smap (V2.0) id
          xma008222; Tue, 25 Jan 00 08:38:30 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id IAA02550 for
          ; Tue, 25 Jan 2000 08:39:31
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAB14CC for
          ; Tue, 25 Jan 2000 08:38:25 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id IAA00961 for ; Tue, 25
          Jan 2000 08:38:06 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id IAA08477
          for ; Tue, 25 Jan 2000 08:38:05
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B29@whq-msgusr-02.fore.com>
            <388C400B.3285040F@lucent.com> <388C640B.BC1D28D8@usa.alcatel.com>
            <388D54D7.8A96D7FC@lucent.com>
Content-Type: multipart/alternative;
              boundary="------------BB2F4C971D594731290DB2FD"
Message-ID:  <388DB54C.A883194D@usa.alcatel.com>
Date:         Tue, 25 Jan 2000 08:38:05 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------BB2F4C971D594731290DB2FD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

My proposal is not clearer but it is comprehensive.  It is the Standard
that is not clearer.
It just happens that the Standard provides 2 ways for MG to announce its
existence to MGC - Restart
or Failover.
Since neither methods guarantee MGC will accept the MG, it is a request for
serivce by MG to me.
Therefore it is like registering for service with different REASON.

Fine, your proposal is ok if your are desscribing how Restart works.

Chuong

John Segers wrote:

> I think that we have a different interpretation of the word
> registration.  In my interpretation registration=restart and
> failover=failover.  In your interpretation, a failover scenario contains
> registration.
>
> Why is your proposal ("A ServiceChange Command specifying the "Root" for
> the TerminationID and ServiceChangeMethod equal to Restart or Failover
> is a registration command by which a Media Gateway announces its
> existence to the Media Gateway Controller") more clear than the existing
> text ("A ServiceChange Command specifying the "Root" for the
> TerminationID is a registration command by which a Media Gateway
> announces its existence to the Media Gateway Controller")?
>
> John
>
> Chuong Nguyen wrote:
> >
> > For either Restart or Failover, one would still has to specify ROOT at
> > the terminationID.
> > Also both methods really resulted in a registration since the MGC
> > receiving this ServiceChange
> > can still deny the registering MG.
> >
> > If you want to change the text then it should be
> > "A ServiceChange Command specifying the "Root" for
> > the TerminationID and ServiceChangeMethod equal to Restart or Failover
> > is a
> > registration command [...]"
> >
> > Chuong
> >
> >
> > John Segers wrote:
> >
> > > Brian, Chuong,
> > >
> > > The current text in Section 7.2.8 (first sentence of sixth paragraph
> > >
> > > after the numbered list of ServiceChangeMethods) reads "A
> > > ServiceChange
> > > Command specifying the "Root" for the TerminationID is a
> > > registration
> > > command [...]"  This does seem to be inconsistent with later
> > > sections.
> > >
> > > How about changing "A ServiceChange Command specifying the "Root"
> > > for
> > > the TerminationID and ServiceChangeMethod equal to Restart is a
> > > registration command [...]" ?
> > >
> > > John
> > >
> > >      There are really 2 methods for registration, Restart or
> > > Failover
> > >
> > >      as being the first message from MG to MGC.  Section 7.2.8
> > > implies
> > >
> > >      only one - Restart w/ROOT.  Section 11.5 implies Failover
> > > w/ROOT.
> > >
> > >      Section 7.2.8 ServiceChange
> > >
> > >      "6. Failover - send from MG to MGC to indicate the primary MG
> > > is
> > > out
> > >
> > >      service and a secondary MG is taking over."
> > >
> > >      This matches section 11.4 but in section 11.5, this method is
> > > also
> > >
> > >      used by MG to register with Primary or Secondary MGC.
> > >
> > >      Does the text need to be cleaned or more clarification?
> > >
> > >      [BR] We should look at that.
> > >
> > > --
> > > John Segers                                  email:
> > > jsegers@lucent.com
> > > Lucent Technologies                                        Room HE
> > > 306
> > > Dept. Forward Looking Work                      phone: +31 35 687
> > > 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687
> > > 5954
> >
> > --
> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >
> >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------BB2F4C971D594731290DB2FD
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



My proposal is not clearer but it is comprehensive.  It is the Standard
that is not clearer.

        It just happens that the Standard provides 2 ways for MG to announce
its existence to MGC - Restart

        or Failover.

        Since neither methods guarantee MGC will accept the MG, it is a request
for serivce by MG to me.

        Therefore it is like registering for service with different REASON.

        Fine, your proposal is ok if your are desscribing how Restart works.

        Chuong

        John Segers wrote:

        I think that we have a different interpretation of
the word

        registration.  In my interpretation registration=restart and

        failover=failover.  In your interpretation, a failover scenario
contains

        registration.

        Why is your proposal ("A ServiceChange Command specifying the "Root"
for

        the TerminationID and ServiceChangeMethod equal to Restart or Failover

        is a registration command by which a Media Gateway announces its

        existence to the Media Gateway Controller") more clear than the existing

        text ("A ServiceChange Command specifying the "Root" for the

        TerminationID is a registration command by which a Media Gateway

        announces its existence to the Media Gateway Controller")?

        John

        Chuong Nguyen wrote:

        >

        > For either Restart or Failover, one would still has to specify ROOT
at

        > the terminationID.

        > Also both methods really resulted in a registration since the MGC

        > receiving this ServiceChange

        > can still deny the registering MG.

        >

        > If you want to change the text then it should be

        > "A ServiceChange Command specifying the "Root" for

        > the TerminationID and ServiceChangeMethod equal to Restart or Failover

        > is a

        > registration command [...]"

        >

        > Chuong

        >

        >

        > John Segers wrote:

        >

        > > Brian, Chuong,

        > >

        > > The current text in Section 7.2.8 (first sentence of sixth paragraph

        > >

        > > after the numbered list of ServiceChangeMethods) reads "A

        > > ServiceChange

        > > Command specifying the "Root" for the TerminationID is a

        > > registration

        > > command [...]"  This does seem to be inconsistent with later

        > > sections.

        > >

        > > How about changing "A ServiceChange Command specifying the "Root"

        > > for

        > > the TerminationID and ServiceChangeMethod equal to Restart is a

        > > registration command [...]" ?

        > >

        > > John

        > >

        > >      There are really 2 methods for registration,
Restart or

        > > Failover

        > >

        > >      as being the first message from MG
to MGC.  Section 7.2.8

        > > implies

        > >

        > >      only one - Restart w/ROOT. 
Section 11.5 implies Failover

        > > w/ROOT.

        > >

        > >      Section 7.2.8 ServiceChange

        > >

        > >      "6. Failover - send from MG to MGC
to indicate the primary MG

        > > is

        > > out

        > >

        > >      service and a secondary MG is taking
over."

        > >

        > >      This matches section 11.4 but in
section 11.5, this method is

        > > also

        > >

        > >      used by MG to register with Primary
or Secondary MGC.

        > >

        > >      Does the text need to be cleaned
or more clarification?

        > >

        > >      [BR] We should look at that.

        > >

        > > --

        > > John Segers                                 
email:

        > > jsegers@lucent.com

        > > Lucent Technologies                                       
Room HE

        > > 306

        > > Dept. Forward Looking Work                     
phone: +31 35 687

        > > 4724

        > > P.O. Box 18, 1270 AA  Huizen                     
fax: +31 35 687

        > > 5954

        >

        > --

        >   Alcatel USA, Inc            
Internet: Chuong.Nguyen@usa.alcatel.com

        >   1000 Coit Road Plano, Texas 75075          
Phone:    (972) 519-4613

        >   **** The opinions expressed are not those of Alcatel
USA, Inc ****

        >

        >

        --

        John Segers                                 
email: jsegers@lucent.com

        Lucent Technologies                                       
Room HE 306

        Dept. Forward Looking Work                     
phone: +31 35 687 4724

        P.O. Box 18, 1270 AA  Huizen                     
fax: +31 35 687 5954
        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------BB2F4C971D594731290DB2FD--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 09:59:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29230
	for ; Tue, 25 Jan 2000 09:59:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9ACA67F0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 9:57:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7382 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 09:56:15 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.6AC59ED0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 9:56:14
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id HAA03338; Tue, 25 Jan 2000 07:57:32
          -0700 (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B78@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------E67D9170306D6BE1D2862C05"
Message-ID:  <388DB9DC.C0947D29@aztek-eng.com>
Date:         Tue, 25 Jan 2000 07:57:33 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      Re: Question about Protocol Version
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------E67D9170306D6BE1D2862C05
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Sorry my question wasn't clear. What I meant to ask is what value
is assigned to version for the current spec? I.e., should the
version in my transaction header be 0.1 or 1.0 or ? For example,
the MGCP spec has a section called "Coding of the protocol
version".

Jo

"Rosen, Brian" wrote:

>  In every transaction header Brian
>
>      -----Original Message-----
>      From: Jo Friedman [mailto:jo@aztek-eng.com]
>      Sent: Monday, January 24, 2000 12:33 PM
>      To: MEGACO@standards.nortelnetworks.com
>      Subject: Re: Question about Protocol Version
>      Negaotiation
>
>      I have a simple, related question. Where is the
>      current MEGACO protocol version identified in the
>      spec? Seems like this is missing.
>
>      Tom-PT Taylor wrote:
>
>     >
>     >
>     > At this point our only backward compatibility
>     > mechanism is the fallback to earlier version.
>     >
>     > You make a good point: there is no message by which
>     > the MG can reject the fallback.  The answer, it
>     > seems to me, is that it doesn't send one -- it
>     > simply doesn't follow up on its original message
>     > and rejects any command the MGC tries to send it.
>     > If it connected to the MGC (e.g. via TCP) it breaks
>     > the connection.
>     >
>     >      -----Original Message-----
>     >      From:   Qiu Xiuping
>     >      [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
>     >      Sent:   Saturday, January 22, 2000 9:51 AM
>     >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>     >      Subject:        Question about Protocol
>     >      Version Negaotiation
>     >
>     >      Hi, All.
>     >
>     >      In 11.3 Negotiation of Protocol Version
>     >
>     >      1. The first ServiceChange command from MG
>     >      contains a version number .
>     >      2. MGC supports only a lower version, then the
>     >      MGC sends a ServiceChangeReply with the lower
>     >      version . 3. If the MG is unable to comply, it
>     >      will reject the association, with Error 406
>     >      Version Not Supported.
>     >
>     >      I wonder what command will MG use in step 3 .
>     >      Will it be notify? but there is no
>     >      EventDescriptor.
>     >      And is it a TransactionRequest , but it is
>     >      with Error code.
>     >      IMO, error code is together with
>     >      TransactionReply but not TransactionRequest ?
>     >
>     >      And another question, I remember it says that
>     >      MEGACO/H.248 will be compatible backwards
>     >      somewhere.
>     >      Then  if both MG and MGC use the lower
>     >      version, why there  still exists complying
>     >      problem.
>     >
>     >      Regards,
>     >      Xiuping Qiu
>     >
>     >      ______________________________________________
>     >
>     >      Xiuping Qiu
>     >      Huawei Technologies Co., Ltd.
>     >      Mail to   qiuxiuping@sz.huawei.com.cn
>     >      Visit     http://www.huawei.com.cn
>     >
>     >      ______________________________________________
>     >

--------------E67D9170306D6BE1D2862C05
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Sorry my question wasn't clear. What I meant to ask is what value is assigned
to version for the current spec? I.e., should the version in my transaction
header be 0.1 or 1.0 or ? For example, the MGCP spec has a section called
"Coding of the protocol version".

        Jo

        "Rosen, Brian" wrote:

         In
every transaction header Brian

        

        -----Original
Message-----

        From: Jo Friedman [mailto:jo@aztek-eng.com]

        Sent: Monday, January 24,
2000 12:33 PM

        To: MEGACO@standards.nortelnetworks.com

        Subject: Re: Question about
Protocol Version Negaotiation

         
        
I have a simple, related question. Where is the current MEGACO protocol
version identified in the spec? Seems like this is missing.

        Tom-PT Taylor wrote:

         

        At this point
our only backward compatibility mechanism is the fallback to earlier version.

        You make a good
point: there is no message by which the MG can reject the fallback. 
The answer, it seems to me, is that it doesn't send one -- it simply doesn't
follow up on its original message and rejects any command the MGC tries
to send it.  If it connected to the MGC (e.g. via TCP) it breaks the
connection.

          -----Original Message-----

          From:  
Qiu Xiuping [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]

          Sent:  
Saturday, January 22, 2000 9:51 AM

          To:    
MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       
Question about Protocol Version Negaotiation

          Hi, All.

          In 11.3 Negotiation of Protocol Version

          1. The first ServiceChange command
from MG contains a version number .

          2. MGC supports only a lower version,
then the MGC sends a ServiceChangeReply with the lower version . 3. If
the MG is unable to comply, it will reject the association, with Error
406 Version Not Supported.

          I wonder what command will MG use in
step 3 .

          Will it be notify? but there is no
EventDescriptor.

          And is it a TransactionRequest , but
it is with Error code.

          IMO, error code is together with TransactionReply
but not TransactionRequest ?

          And another question, I remember it
says that MEGACO/H.248 will be compatible backwards somewhere.

          Then  if both MG and MGC use
the lower version, why there  still exists complying problem.

          Regards,

          Xiuping Qiu

          _______________________________________________

          Xiuping Qiu

          Huawei Technologies Co., Ltd.

          Mail to   qiuxiuping@sz.huawei.com.cn

          Visit     http://www.huawei.com.cn

          _______________________________________________
        

        

        

        


--------------E67D9170306D6BE1D2862C05--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 10:34:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00613
	for ; Tue, 25 Jan 2000 10:33:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DD15430@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:31:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7447 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 10:30:38 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.28ECF180@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:23:02
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA17621 for
          ; Tue, 25 Jan 2000 20:39:16
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256871.0050161D ; Tue, 25 Jan 2000 20:04:45 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=caeFPC3hJky5Ganph3p5cmp5iN5BzGxJbsMyArCfWSfSnI55JKFQLWXf"
Content-Disposition: inline
Message-ID:  <65256871.005014C3.00@sandesh.hss.hns.com>
Date:         Tue, 25 Jan 2000 20:08:04 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Subtract Command with wildcard Termination Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=caeFPC3hJky5Ganph3p5cmp5iN5BzGxJbsMyArCfWSfSnI55JKFQLWXf
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG that choose
 the context  in which the given Termination exist and subtract the termination.




"Rosen, Brian"  on 01/25/2000 08:39:42 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Subtract Command with wildcard Termination Name




I think this is headed in the wrong direction.  Subtract of wildcarded
contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

It is also useful in a wildcard Audit, with or without W-.

So I think it is allowed, period.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, January 24, 2000 10:06 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Subtract Command with wildcard Termiantion Name



Your question has a couple of wider implications.  My first reaction was to
say this was an error, because in principle the MGC can always know which
context a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine the
current context of a termination if it doesn't know it already.

I think the answer has to be that we change the production auditOther to
include the context ID.

e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

Then the answer to your original question is that it is an error.

        -----Original Message-----
From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Subtract Command with wildcard Termiantion Name

        Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

        Regards
MadhuBabu



--0__=caeFPC3hJky5Ganph3p5cmp5iN5BzGxJbsMyArCfWSfSnI55JKFQLWXf
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U
RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4NTktMSI+DQo8VElUTEU+UkU6IFN1YnRyYWN0
IENvbW1hbmQgd2l0aCB3aWxkY2FyZCBUZXJtaWFudGlvbiBOYW1lPC9USVRMRT4NCg0KPE1FVEEg
Y29udGVudD0iTVNIVE1MIDUuMDAuMjYxNC4zNDAxIiBuYW1lPUdFTkVSQVRPUj48L0hFQUQ+DQo8
Qk9EWT4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBj
bGFzcz02MjA0NTQ3MDItMjUwMTIwMDA+SQ0KdGhpbmsgdGhpcyBpcyBoZWFkZWQgaW4gdGhlIHdy
b25nIGRpcmVjdGlvbi4mbmJzcDsgU3VidHJhY3Qgb2Ygd2lsZGNhcmRlZA0KY29udGV4dElkIHdh
cyBleHBsaWNpdGx5IGFsbG93ZWQgZm9yLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U
IGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9NjIwNDU0NzAyLTI1
MDEyMDAwPmFtb25nDQpvdGhlciB0aGluZ3MsIHRoZSByZXNwb25zZSB0byBhIFNlcnZpY2VDaGFu
Z2Ugd2l0aCBtYXNzIG91dCBvZiBzZXJ2aWNlDQpvcGVyYXRpb25zIHBlbmRpbmcuPC9TUEFOPjwv
Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj48
U1BBTiBjbGFzcz02MjA0NTQ3MDItMjUwMTIwMDA+VGhlDQpNR0MgbXVzdCBzdWJ0cmFjdCBhbGwg
Y2FsbHMsIGFuZCBkbyBpdCBpbiBhIGh1cnJ5LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
T05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4NCmNsYXNzPTYyMDQ1NDcw
Mi0yNTAxMjAwMD48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0j
MDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTYyMDQ1NDcwMi0yNTAxMjAwMD5J
dCBpcw0KYWxzbyB1c2VmdWwgaW4gYSB3aWxkY2FyZCBBdWRpdCwgd2l0aCBvciB3aXRob3V0IFct
LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1Bcmlh
bCBzaXplPTI+PFNQQU4NCmNsYXNzPTYyMDQ1NDcwMi0yNTAxMjAwMD48L1NQQU4+PC9GT05UPiZu
YnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPjxT
UEFOIGNsYXNzPTYyMDQ1NDcwMi0yNTAxMjAwMD5TbyBJDQp0aGluayBpdCBpcyBhbGxvd2VkLCBw
ZXJpb2QuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNl
PUFyaWFsIHNpemU9Mj48U1BBTg0KY2xhc3M9NjIwNDU0NzAyLTI1MDEyMDAwPjwvU1BBTj48L0ZP
TlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwZmYgZmFjZT1BcmlhbCBzaXpl
PTI+PFNQQU4NCmNsYXNzPTYyMDQ1NDcwMi0yNTAxMjAwMD5CcmlhbjwvU1BBTj48L0ZPTlQ+PC9E
SVY+DQo8QkxPQ0tRVU9URQ0Kc3R5bGU9IkJPUkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsg
TUFSR0lOLUxFRlQ6IDVweDsgUEFERElORy1MRUZUOiA1cHgiPg0KICA8RElWIGFsaWduPWxlZnQg
Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0cj48Rk9OVCBmYWNlPVRhaG9tYQ0KICBz
aXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+PEI+RnJvbTo8L0I+IFRvbS1QVCBU
YXlsb3INCiAgW21haWx0bzp0YXlsb3JAbm9ydGVsbmV0d29ya3MuY29tXTxCUj48Qj5TZW50Ojwv
Qj4gTW9uZGF5LCBKYW51YXJ5IDI0LCAyMDAwDQogIDEwOjA2IEFNPEJSPjxCPlRvOjwvQj4gTUVH
QUNPQHN0YW5kYXJkcy5ub3J0ZWxuZXR3b3Jrcy5jb208QlI+PEI+U3ViamVjdDo8L0I+DQogIFJl
OiBTdWJ0cmFjdCBDb21tYW5kIHdpdGggd2lsZGNhcmQgVGVybWlhbnRpb24gTmFtZTxCUj48QlI+
PC9ESVY+PC9GT05UPg0KICA8UD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0y
PllvdXIgcXVlc3Rpb24gaGFzIGEgY291cGxlIG9mIHdpZGVyDQogIGltcGxpY2F0aW9ucy4mbmJz
cDsgTXkgZmlyc3QgcmVhY3Rpb24gd2FzIHRvIHNheSB0aGlzIHdhcyBhbiBlcnJvciwgYmVjYXVz
ZSBpbg0KICBwcmluY2lwbGUgdGhlIE1HQyBjYW4gYWx3YXlzIGtub3cgd2hpY2ggY29udGV4dCBh
IHRlcm1pbmF0aW9uIGlzIGluLCB0aHJvdWdoDQogIGF1ZGl0cyBpZiBuZWNlc3NhcnkuJm5ic3A7
IFRoZW4gSSBjaGVja2VkIG91dCBvdXIgYXVkaXQgcmVzcG9uc2Ugc3ludGF4IGFuZA0KICByZWFs
aXplZCB0aGF0IHRoZSBNR0MgY2Fubm90IGRldGVybWluZSB0aGUgY3VycmVudCBjb250ZXh0IG9m
IGEgdGVybWluYXRpb24gaWYNCiAgaXQgZG9lc24ndCBrbm93IGl0IGFscmVhZHkuPC9GT05UPjwv
UD4NCiAgPFA+PEZPTlQgY29sb3I9IzAwMDBmZiBmYWNlPUFyaWFsIHNpemU9Mj5JIHRoaW5rIHRo
ZSBhbnN3ZXIgaGFzIHRvIGJlIHRoYXQgd2UNCiAgY2hhbmdlIHRoZSBwcm9kdWN0aW9uIGF1ZGl0
T3RoZXIgdG8gaW5jbHVkZSB0aGUgY29udGV4dCBJRC48L0ZPTlQ+IDxCUj48Rk9OVA0KICBjb2xv
cj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyA8L0ZPTlQ+PEJSPjxGT05UIGNvbG9y
PSMwMDAwZmYNCiAgZmFjZT1BcmlhbCBzaXplPTI+ZS5nLjwvRk9OVD4gPEZPTlQgZmFjZT0iQ291
cmllciBOZXciIHNpemU9Mj5hdWRpdE90aGVyID0NCiAgRVFVQUwgVGVybWluYXRpb25JRCBMQlJL
VDwvRk9OVD4mbmJzcDs8Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiBDdHhUb2tlbg0KICBF
UVVBTCBDb250ZXh0SUQmbmJzcDsgdGVybWluYXRpb25BdWRpdCBSQlJLVDwvRk9OVD4gPC9QPg0K
ICA8UD48Rk9OVCBjb2xvcj0jMDAwMGZmIGZhY2U9QXJpYWwgc2l6ZT0yPlRoZW4gdGhlIGFuc3dl
ciB0byB5b3VyIG9yaWdpbmFsDQogIHF1ZXN0aW9uIGlzIHRoYXQgaXQgaXMgYW4gZXJyb3IuPC9G
T05UPiA8L1A+DQogIDxVTD4NCiAgICA8UD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT4tLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTwvRk9OVD4gPEJSPjxCPjxGT05UDQogICAgZmFjZT1BcmlhbCBz
aXplPTE+RnJvbTombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBmYWNlPUFyaWFsDQogICAg
c2l6ZT0xPlNhY2hpbiBNaXR0YWwgW1NNVFA6c2FtaXR0YWxASFNTLkhOUy5DT01dPC9GT05UPiA8
QlI+PEI+PEZPTlQNCiAgICBmYWNlPUFyaWFsIHNpemU9MT5TZW50OiZuYnNwOyZuYnNwOzwvRk9O
VD48L0I+IDxGT05UIGZhY2U9QXJpYWwNCiAgICBzaXplPTE+U3VuZGF5LCBKYW51YXJ5IDIzLCAy
MDAwIDExOjU2IFBNPC9GT05UPiA8QlI+PEI+PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9MT5U
bzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBmYWNlPUFyaWFsDQog
ICAgc2l6ZT0xPk1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPiA8QlI+
PEI+PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9MT5TdWJqZWN0OiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvRk9OVD48L0I+IDxGT05UDQogICAgZmFjZT1Bcmlh
bCBzaXplPTE+U3VidHJhY3QgQ29tbWFuZCB3aXRoIHdpbGRjYXJkIFRlcm1pYW50aW9uIE5hbWU8
L0ZPTlQ+DQo8L1A+DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+SGkhPC9GT05UPiA8
QlI+PEZPTlQgZmFjZT1BcmlhbA0KICAgIHNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
SGVyZSBpcyBhIHNtYWxsIHF1ZXJ5IHJlZ2FyZGluZyB0aGUgY2FzZQ0KICAgIHdoZXJlIENvbnRl
eHRJRCBpcyAiKiIgYW5kPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+VGVybWlu
YXRpb24NCiAgICBOYW1lIGlzIGZ1bGx5LXNwZWNpZmllZC4gRG9lcyB0aGlzIGltcGxpZXMgdGhh
dCBNR0MgaW50ZW5kcyB0bzwvRk9OVD4NCiAgICA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+
U3VidHJhY3QgdGhlIHNwZWNpZmljIHRlcm1pbmF0aW9uIGZyb208L0ZPTlQ+DQogICAgPEJSPjxG
T05UIGZhY2U9QXJpYWwgc2l6ZT0yPiJ3aGljaGV2ZXIiIGNvbnRleHQgaXQgYXBwZWFycyBpbiA/
IE9yIGl0IGlzIGFuDQogICAgZXJyb3IgYmVjYXVzZSBhIHRlcm1pbmF0aW9uIGNhbjwvRk9OVD4g
PEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPmV4aXN0DQogICAgb25seSBpbiBvbmUgY29udGV4
dCBhbmQ8L0ZPTlQ+IDxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5Db250ZXh0SUQgPSAiKiIN
CiAgICBmb3IgYSBzcGVjaWZpYyB0ZXJtaW5hdGlvbiBpcyBhbiBlcnJvciA/PC9GT05UPiA8L1A+
DQogICAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+UmVnYXJkczwvRk9OVD4gPEJSPjxGT05U
IGZhY2U9QXJpYWwNCiAgICBzaXplPTI+TWFkaHVCYWJ1PC9GT05UPiA8L1A+PC9VTD48L0JMT0NL
UVVPVEU+PC9CT0RZPjwvSFRNTD4NCg0K

--0__=caeFPC3hJky5Ganph3p5cmp5iN5BzGxJbsMyArCfWSfSnI55JKFQLWXf--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 10:40:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00807
	for ; Tue, 25 Jan 2000 10:40:00 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3568D3A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:37:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7444 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 10:37:05 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.B6221530@standards.nortelnetworks.com>;
          Tue, 25 Jan 2000 10:26:59 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id JAA15087
          for ; Tue, 25 Jan 2000 09:28:17
          -0600 (CST)
Received: from relay2.dsccc.com(10.17.102.19) by fw3 via smap (V2.0) id
          xma014925; Tue, 25 Jan 00 09:27:30 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id JAA13634 for
          ; Tue, 25 Jan 2000 09:28:28
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA5A85 for
          ; Tue, 25 Jan 2000 09:27:23 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id JAA09236 for ; Tue, 25
          Jan 2000 09:26:53 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id JAA08491
          for ; Tue, 25 Jan 2000 09:26:52
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------964D2D477F988F531BB6E40C"
Message-ID:  <388DC0BC.56E6373E@usa.alcatel.com>
Date:         Tue, 25 Jan 2000 09:26:52 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Subtract Command with wildcard Termination Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------964D2D477F988F531BB6E40C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is the following what you want to do?

Transaction=1000{Context=*{AuditValue=T123}}
Reply = 1000{Context=2222{AuditValue=Context{T123}}

or

Transaction=1000{Context=*{AuditValue=*}}
Reply = 1000{Context=2222{AuditValue=Context{T123},
                         Context=3333{AuditValue=Context{T222,T333},
                         Context=.....}

If yes, this is already taken into account by the current ABNF.

Chuong

Tom-PT Taylor wrote:

>
>
> OK, this is the second comment I've had to this effect -- the other
> was received privately.  The one question is whether we want a way to
> find out what context a termination is in without subtracting it to
> find out, in which case the audit response syntax I suggested might be
> considered.  Silence means we don't need this additional
> functiuonality.
>
>      -----Original Message-----
>      From:  Rosen, Brian [SMTP:brosen@fore.com]
>      Sent:  Monday, January 24, 2000 10:10 PM
>      To:    Taylor, Tom-PT [CAR:B904:EXCH];
>      MEGACO@standards.nortelnetworks.com
>      Subject:       RE: Subtract Command with wildcard Termination
>      Name
>
>      I think this is headed in the wrong direction.  Subtract of
>      wildcarded contextId was explicitly allowed for,
>      among other things, the response to a ServiceChange with mass out
>      of service operations pending.
>      The MGC must subtract all calls, and do it in a hurry.
>
>      It is also useful in a wildcard Audit, with or without W-.
>
>      So I think it is allowed, period.
>
>      Brian
>           -----Original Message-----
>           From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>           Sent: Monday, January 24, 2000 10:06 AM
>           To: MEGACO@standards.nortelnetworks.com
>           Subject: Re: Subtract Command with wildcard Termiantion Name
>
>
>
>           Your question has a couple of wider implications.  My first
>           reaction was to say this was an error, because in principle
>           the MGC can always know which context a termination is in,
>           through audits if necessary.  Then I checked out our audit
>           response syntax and realized that the MGC cannot determine
>           the current context of a termination if it doesn't know it
>           already.
>
>           I think the answer has to be that we change the production
>           auditOther to include the context ID.
>
>           e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
>           ContextID  terminationAudit RBRKT
>
>           Then the answer to your original question is that it is an
>           error.
>
>                   -----Original Message-----
>           From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>           Sent:   Sunday, January 23, 2000 11:56 PM
>           To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>           Subject:       Subtract Command with wildcard Termiantion
>           Name
>
>                   Hi!
>                Here is a small query regarding the case where
>           ContextID is "*" and
>           Termination Name is fully-specified. Does this implies that
>           MGC intends to
>           Subtract the specific termination from
>           "whichever" context it appears in ? Or it is an error
>           because a termination can
>           exist only in one context and
>           ContextID = "*" for a specific termination is an error ?
>
>                   Regards
>           MadhuBabu
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------964D2D477F988F531BB6E40C
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Is the following what you want to do?

        Transaction=1000{Context=*{AuditValue=T123}}

        Reply = 1000{Context=2222{AuditValue=Context{T123}}

        or

        Transaction=1000{Context=*{AuditValue=*}}

        Reply = 1000{Context=2222{AuditValue=Context{T123},

                                
Context=3333{AuditValue=Context{T222,T333},

                                
Context=.....}

        If yes, this is already taken into account by the current ABNF.

        Chuong

        Tom-PT Taylor wrote:

         

        OK, this is the
second comment I've had to this effect -- the other was received privately. 
The one question is whether we want a way to find out what context a termination
is in without subtracting it to find out, in which case the audit response
syntax I suggested might be considered.  Silence means we don't need
this additional functiuonality.

          -----Original Message-----

          From:  Rosen, Brian [SMTP:brosen@fore.com]

          Sent:  Monday, January
24, 2000 10:10 PM

          To:    Taylor,
Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com

          Subject:      
RE: Subtract Command with wildcard Termination Name

          I think this
is headed in the wrong direction.  Subtract of wildcarded contextId
was explicitly allowed for,

          among other
things, the response to a ServiceChange with mass out of service operations
pending.

          The MGC must
subtract all calls, and do it in a hurry.

          It is also useful
in a wildcard Audit, with or without W-.

          So I think it
is allowed, period.

          Brian

            -----Original Message-----

            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

            Sent: Monday, January 24,
2000 10:06 AM

            To: MEGACO@standards.nortelnetworks.com

            Subject: Re: Subtract Command
with wildcard Termiantion Name

             

            Your question
has a couple of wider implications.  My first reaction was to say
this was an error, because in principle the MGC can always know which context
a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine
the current context of a termination if it doesn't know it already.

            I think the answer
has to be that we change the production auditOther to include the context
ID.

            e.g.auditOther
= EQUAL TerminationID LBRKT 
CtxToken EQUAL ContextID  terminationAudit RBRKT

            Then the answer
to your original question is that it is an error.

                    -----Original
Message-----

            From:   Sachin
Mittal [SMTP:samittal@HSS.HNS.COM]

            Sent:   Sunday,
January 23, 2000 11:56 PM

            To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

            Subject:      
Subtract Command with wildcard Termiantion Name

                    Hi!

                 Here is a
small query regarding the case where ContextID is "*" and

            Termination Name is fully-specified.
Does this implies that MGC intends to

            Subtract the specific termination
from

            "whichever" context it appears in
? Or it is an error because a termination can

            exist only in one context and

            ContextID = "*" for a specific termination
is an error ?

                    Regards

            MadhuBabu
          

        

        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------964D2D477F988F531BB6E40C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 11:00:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01691
	for ; Tue, 25 Jan 2000 11:00:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.02B92E70@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:57:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7503 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 10:57:01 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.E7D86210@standards.nortelnetworks.com>; Tue, 25 Jan 2000 10:57:00
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id IAA05390 for
          ; Tue, 25 Jan 2000 08:58:24
          -0700 (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF1A0B79@whq-msgusr-02.fore.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388DC821.368386C0@aztek-eng.com>
Date:         Tue, 25 Jan 2000 08:58:25 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      Re: DTMF and Signals descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Brian,
You made two statements below that aren't explicitly stated in the spec and
probably would have helped me understand signals better.

"Since the default SignalType for dtmf digits is BRief, the duration is
fixed (or provisioned) it could be overriden by using the duration parameter"

"A normal signal has a default duration ...."

Since signalType and duration are optional  should the default signalType and
duration  values be specified in the package? This is actually stated in 12.1.4,
but the packages in Annex E (e.g., basic DTMF generator) don't define these
default values. I think this is where I got confused.

Jo

"Rosen, Brian" wrote:

> See comments below
>
> > -----Original Message-----
> > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > Sent: Monday, January 24, 2000 5:42 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: DTMF and Signals descriptor
> >
> >
> > Please tell me if I'm correct in assuming that there are at least
> > two ways for the MGC to request the MG to signal DTMF digits on a
> > physical termination. I also have some V13 comments related to
> > the signal descriptor below.
> >
> > Are both of these correct for dialing '125'?
> >
> > Signals {
> >    dg/pt {
> >       ind=100,         ; interdigit duration
> >       tl=[d1,d2,d5]   ; dtmf digits 125
> >    }
> > }
> > In this case how is the signal duration specified?
> Since the default SignalType for dtmf digits is BRief, the duration is
> fixed (or provisioned) it could be overriden by using the duration parameter
>
> to specify something else.  SignalType and Duration are available for every
> signal.
>
> >
> > or
> >
> > SignalList = 10 {
> >    SignalType=Timeout,
> >    Duration=250,
> >    dg/d1,
> >    dg/d2,
> >    dg/d5
> > }
> Yes
>
> > V13 comments:
> > In 7.1.11 the last sentence of the 1st paragraph refers to
> > "sequential play lists". I assume that is the same as "sequential
> > signal lists" so it should be replaced to avoid confusion.
> Yes, we should fix this
>
> >
> > In the ABNF for signalListParm the preceding comments contains
> > the phrase "at most once duration and every signal parameter". I
> > understand "at most once duration" but I don't understand what is
> > meant to be conveyed by the rest of the phrase.
> I think it means that a parameter to a signal can only occur once per
> signal instance in the list (but signal can occur more than once, and
> in each case signal parameters can be included (once).
>
> >
> > In the ABNF for signalListParm if SigSignalType=Timeout is
> > sigDuration required? The description of timeout in 7.1.11
> > implies if there is no duration the signal is played until it is
> > turned off. In a signal list this doesn't make sense because the
> > first signal in the list would be the only signal played,
> > wouldn't it?
> I don't think we talked about this.  A normal signal has a default duration
> and if not specified, that is what you use.  A signal list does not have
> a default duration.  At the moment, I'd say it's an error to specify
> SignalType = TimeOut and not specify Duration.
>
> >
> > Thanks for any clarifications!
> > Jo
> >
>
> Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 12:01:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03626
	for ; Tue, 25 Jan 2000 12:01:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B218E30@standards.nortelnetworks.com>; Tue, 25 Jan 2000 11:58:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7552 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 11:57:06 -0500
Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1a) with SMTP id
          <0.4CF4CEB0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 11:57:06
          -0500
Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com
          (8.9.3+Sun/8.9.3) with ESMTP id JAA08116 for
          ; Tue, 25 Jan 2000 09:58:30
          -0700 (MST)
X-Mailer: Mozilla 4.51 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <388DD637.66605BC2@aztek-eng.com>
Date:         Tue, 25 Jan 2000 09:58:31 -0700
Reply-To: Jo Friedman 
Sender: "Media Gateway Control (megaco)"
              
From: Jo Friedman 
Organization: Aztek Engineering
Subject:      O- and W- in ABNF
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

It seems that "O-" used in commandRequestList and "W-" used in
subtractRequest and auditRequest are not described anywhere.

An archived message from Nancy stated that: "Megaco/H.248 does
have a way to mark a command as optional (O-)" and this
corresponds to the discussion of optional in section 8.

I'm guessing that W- corresponds to this statement found in 7.2.5
and 7.2.6:
"If the TerminationId is wildcarded, only one command return is
generated, with the contents containing the union of the values
of all Terminations matching the wildcard." (Note this statement
is missing from the Subtract command in 7.2.3). Did I guess
correctly?

These notations should be better documented in the spec,
especially for those of us who don't know the secret handshake.

Thanks,
Jo


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 14:17:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06503
	for ; Tue, 25 Jan 2000 14:17:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.991C3860@standards.nortelnetworks.com>; Tue, 25 Jan 2000 14:15:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7861 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 14:14:01 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6D188520@standards.nortelnetworks.com>; Tue, 25 Jan 2000 14:14:00
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id LAA05309
          for ; Tue, 25 Jan 2000 11:15:41
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000125135828.00ade780@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 14:01:25 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Delayed Contribution on H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Below is a URL to a contribution submitted to ITU SG16 on H.248 containing
comments against the white contribution (v12).
ftp://standard.pictel.com/avc-site/Incoming/h248_comments_Cisco.zip

I am planning to post these to the list as soon as I can organize them
according to subject.

Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 15:06:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07200
	for ; Tue, 25 Jan 2000 15:06:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A89F890@standards.nortelnetworks.com>; Tue, 25 Jan 2000 15:04:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8000 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 15:03:41 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1BD98320@standards.nortelnetworks.com>; Tue, 25 Jan 2000 14:54:41
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id BAA01674 for
          ; Wed, 26 Jan 2000 01:54:46
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256871.006CF8B8 ; Wed, 26 Jan 2000 01:20:15 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256871.006CF79A.00@sandesh.hss.hns.com>
Date:         Wed, 26 Jan 2000 01:23:37 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Madhu Babu 
Subject:      Stopping of Dial tone
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi all,

According to the example in the Appendix A.1.2 when MGC request
MG to apply dial tone and check for digit events it is specified
as

Events = 2223 {
al/on, dd/ce {DigitMap=Dialplan0}
}
Signals {cg/dt},

According to the protocol an signal is stopped Whenever any
event occurs. and here the event requested by MGC is digitmap
completion,that means dial tone will be stopped when we get
all the digits (as implied by the name digitmap completion).
What I suggest is that a new event like  "firstdigitcompletion"
should also  be specified, otherwise how can the first digit itself
stops the dialtone.

regards
-Madhubabu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 15:49:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07630
	for ; Tue, 25 Jan 2000 15:49:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80F08E00@standards.nortelnetworks.com>; Tue, 25 Jan 2000 15:47:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8087 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 15:45:59 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.467D7B20@standards.nortelnetworks.com>; Tue, 25 Jan 2000 15:45:59
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id
          PAA10038 for ; Tue, 25 Jan 2000
          15:47:41 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256871.00723B38 ; Tue, 25 Jan 2000 15:47:42 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256871.00723A66.00@notes950.cc.telcordia.com>
Date:         Tue, 25 Jan 2000 15:49:30 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Additional Delayed Contributions on H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Below is a URL to several contributions submitted to ITU SG16 on H.248
containing
comments against the white contribution (v12).

ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-announcements.DOC
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-callerid.DOC
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-callinfo.DOC
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-tones.DOC
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248_asn1-tagging.DOC

I am planning to post these to the list as soon as time permits.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 17:02:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08651
	for ; Tue, 25 Jan 2000 17:02:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71FBC630@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:58:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8197 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 16:57:52 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.51657D30@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:57:52
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id NAA09700
          for ; Tue, 25 Jan 2000 13:59:33
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151300.00b882a0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 16:51:46 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Max Terminations
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:                6.1, fourth paragraph
Category:               Technical
Issue:                  The draft text specifies that "The maximum number
of Terminations in a Context is a MG property." However, no mechanism is
defined for an MGC to determine this property, and consequently the MGC can
only determine this by MG failure.
Proposal:               It is recommended that a Base Root Package with
this property is defined.

v13 Status:     CLOSED. Base Root package with MaxTerminationsPerContext
property added.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 17:02:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08653
	for ; Tue, 25 Jan 2000 17:02:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.723E9B90@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:58:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8202 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 16:57:56 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.53425380@standards.nortelnetworks.com>; Tue, 25 Jan 2000 16:57:55
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id NAA09734
          for ; Tue, 25 Jan 2000 13:59:37
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000125164827.00ad8d80@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 16:51:31 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      SG16 contribution issues
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I will be emailing the issues raised in our SG16 contribution to the megaco
list.

I tried to sort them according to subject matter.  In addition, I have
tried to flag those issues that we consider to have been closed by v13 of
the megaco spec.

I've put "Cisco SG16" at the beginning of the Subject line of each email to
flag it as pertaining to our contribution.

Chip
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 17:20:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08832
	for ; Tue, 25 Jan 2000 17:20:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3FB2AB00@standards.nortelnetworks.com>; Tue, 25 Jan 2000 17:18:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8251 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 17:17:17 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.078EDF50@standards.nortelnetworks.com>; Tue, 25 Jan 2000 17:17:17
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id OAA17879
          for ; Tue, 25 Jan 2000 14:18:57
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000124155814.00aad950@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 17:17:03 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Root Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA08832

Section:        6.2.3
Category:       Open Issue
Issue:          The draft text does not address packages adding properties to root. 
This issue was identified by the IETF editor but has not yet been resolved 
(issue 3). The issue is, that some packages need a property which is the 
same for all terminations that implement the package. Quantify of is an 
example, or bandwidth perhaps.
Discussion:             A continuation of the discussion that has occurred on the 
Megaco mailing list so far is needed in order to resolve the issue.

v13 Status:             Partially CLOSED ? Section 6.2.4 states that “A property may 
be declared as “Global” which has a single value shared by all terminations 
realizing the package”. Not clear how this value is synchronized between 
terminations as there are no rules for how and when updates can be made 
(e.g. by multiple terminations simultaneously ?).  There are no procedures 
in Section 12 on how to declare a value as Global.
Suggested Text is welcome.


Section:        8.2.3, third paragraph
Category:       Technical
Issue:          The draft text specifies that “A property of root 
(normalMGExecutionTime) is settable…Another property 
(normalMGCExecutionTime) is settable…”. Neither of these properties are 
defined anywhere else and their definition as stated here are slightly 
inaccurate as they ignore network transit time.
Proposal:       It is recommended that a Base Root Package with these properties 
are defined. Furthermore, it is recommended to clarify the description of 
these two properties to reflect the fact that they only account for 
processing time in a node and do not include any network delays, thus they 
do specify an absolute value for when a response might be expected.

v13 Status:     SEMI-CLOSED. A base root package with the two properties has 
been defined.  Suggest adding the following text to the description of each 
timer:  "This timer must take into account processing delay in the (MGC or 
MG) in addition to network transit delay."


Section:        D.1.4, second paragraph
Category:       Technical
Issue:          The draft text specifies that “The root termination has a property 
(ProvisionalResponseTimerValue), which can be set to the requested…”. 
However, this property is not defined anywhere else in the document.
Proposal:       It is recommended that a Base Root Package with this property is 
defined.

v13 Status:     CLOSED.  Added to root package E.2.1.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 18:23:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09745
	for ; Tue, 25 Jan 2000 18:23:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E9D90AE0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:20:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8271 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 18:18:56 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A4851650@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:18:56
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA11934
          for ; Tue, 25 Jan 2000 15:20:37
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152608.00b75460@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 18:15:52 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Auditing
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.12, table
Category:       Technical
Issue:          The draft text lists "Extensions" as auditable items,
however the rest of the draft recommendation does not define how auditing
of extensions is performed.
Proposal:       It is recommend, that the example API and the protocol
syntax are extended to include auditing of extensions.

v13 Status:     The new draft has removed extensions from the table.   The
implications are there are no extensions to descriptors allowed in the new
draft, only extensions to parameters(?).  Also, there is no way to audit
for extensions.


Section:        7.2.6, last line
Category:       Technical
Issue:          The draft text specifies that "DigitMap and Packages are
not legal in AuditCapability". This is inconsistent with the return
parameters shown for the example API. Furthermore, it would seem reasonable
to be able determine what packages a termination (or gateway) supports as
well as whether digit map is supported or not. Although packages can be
audited with AuditValue, it would seem to make more sense to allow it in
AuditCapability.
Proposal:       It is proposed to strike the above sentence and allow for
auditing of these two capabilities.

v13 Status:     OPEN. No relevant text changed.


Section:        7.2.6
Category:       Open Issue
Issue:          The current draft text does not specify how to audit
ephemerals at startup. This issue was identified by the IETF editor but has
not yet been resolved (issue 1). The issue is, that when you boot and have
not yet created any ephemeral terminations, how do you know what the MG can
do. For example, how do you know if the MG has say an IP interface, and ATM
interface, an MPLS interface or a Frame Relay interface . If you could
audit something, you could look at the "network" value in LocalControl.
Discussion:             A continuation of the discussion that has occurred
on the Megaco mailing list so far is needed in order to resolve the issue.

v13 Status:     OPEN. No relevant text has been added.







Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 18:31:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09974
	for ; Tue, 25 Jan 2000 18:31:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08FBD140@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:28:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8293 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 18:27:53 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E4692D50@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:27:53
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA15371
          for ; Tue, 25 Jan 2000 15:29:35
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151554.00c01670@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 18:22:52 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      BufferedEventHandling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.7
Category:       Technical, Open Issue
Issue:          At the end of the Red Bank meeting, Section 7.1.7 on
LocalControlDescriptor (Section 7.1.8 in TD-58 from the Red Bank meeting
[3]), contained the following text: "The TerminationBuffered parameter
describes actions taken by the MG when events are not immediately notified
to the controller.
1.      BufferedEventProcessingMode  specifies whether buffered events should be
processed (Process) or discarded (Discard)
2.      BufferedEventNotificationMode  specifies whether the Media Gateway is
expected to detect the requested event and notify the controller once (step
by step) or repeatedly (Loop).
The white contribution does not contain this text which constitutes a
significant technical change to the operation of event detection and
notification which we strongly disagree with.
Discussion:             It is recommended that the above deleted text is added to
Section 7.1.7 again.

v13 Status:     WIDE OPEN. Text still missing. Extensive modification of entire
event processing has taken place.


Section:        7.2.7, second last paragraph
Category:       Technical, Open Issue
Issue:          The draft text specifies that "If the BufferedEventProcessingMode
parameter of the Termination is set to "Discard", then the list shall
contain only the event that triggered the notification".
This constitutes a significant technical change to the operation of event
detection as indicated earlier for Section 7.1.7. The text was not present
at the end of the Red Bank meeting [3], nor should it be. Furthermore, the
text does not seem to make much sense; if an event is not to be reported,
then it is simply not included in the EventsDescriptor. This relates to the
removal of the BufferedEventNotificationMode which should not have happened.
Discussion:     It is strongly recommended that the specification on event
buffering concerning both notification and processing is revisited and
brought back in line with the outcome of the Red Bank meeting.

v13 Status:     OPEN. Although the text has been removed, it is part of an
extensive modification of the entire event handling mechanism.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:02:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10383
	for ; Tue, 25 Jan 2000 19:02:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6030F6D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:59:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8346 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 18:57:59 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.191CDBB0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 18:57:59
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id PAA25776
          for ; Tue, 25 Jan 2000 15:59:41
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152155.00bc5100@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 18:57:35 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  DigitMaps
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.13
Category:       Technical
Issue:          The draft text does not include any rules for when the "current
dial string" is cleared. Rules in this area are needed to provide
consistent operation
Proposal:       It is proposed that the "current dial string" is cleared whenever
a notification occurs, or an Embedded Events Descriptor is activated.

v13 Status:     OPEN. No relevant text added.


Section:        7.1.13, bullet list
Category:       Technical
Issue:          The draft text specifies that digit maps are shared if they are
applied to multiple terminations through wildcarded commands. Furthermore,
the second bullet specifies that "A DigitMap value is updated by supplying
a new value for a name that is already defined". When a shared named digit
map is later changed in a command that is applied only to a particular
termination, this will then modify other terminations view of the digit
map. Furthermore, it is unclear what will happen to any ongoing digit map
matching that is in process at the time this happens.
Proposal:       It is recommended, that when a shared named digit map is modified
in a command that is applied to a termination, the termination does a
copy-and-write and only the termination's digit map is modified; the shared
named digit map is not affected.
v13 Status:     OPEN. No text changed.


Section:        7.1.13, second paragraph.
Category:       Technical
Issue:          The draft text specifies that "A DigitMap, once defined, can be
used on all Terminations specified by the (possibly wildcarded)
TerminationID in such a command". This definition effectively prevents
ephemeral terminations from referencing DigitMaps by name, as ephemeral
terminations cease to exist once they are subtracted from a context. An
example application that might want to use DigitMaps on ephemeral
terminations is an IVR.
Proposal:       It is recommended, that the mechanism is extended to allow
ephemeral terminations to reference a set of DigitMaps by name as well,
e.g. by defining a global digit map name space.

v13 Status:     OPEN. No text changed.


Section:        7.1.13, third paragraph and second number list item.
Category:       Technical/Editorial
Issue:          The draft text for numbered items 2 and 3 specify that "If the
Media Gateway can determine that at least one more digit is needed for a
digit string to match any of the allowed patterns in the digit map, then
the interdigit timer value should be set to a long duration (e.g. 16
seconds)" and "If the DigitMap specifies that a variable number of
additional digits may be needed then the short timer is used". However,
this text specifying an algorithm for determining the current value of the
interdigit timer is inconsistent with the definition of digit map given in
Annex A.3 where two explicitly different timers are defined for the digit
map, hence overriding the algorithm just specified (also note, that there
is an inherent problem in using multiple timer symbols, in that a given
current dial string may match multiple entries in a digit map, one of which
may specify a short timer, and one of which may specify a long timer  which
timer should then be used ?)
Proposal:       It is proposed that the algorithm is retained and only a single
timer symbol ("T") be allowed in digit maps thereby making timer
determination simple and deterministic.

v13 Status:     OPEN. No relevant text changed.


Section:        A.3
Category:       Technical
Issue:          The draft text specifies that two different timer symbols ("S" and
"L") for short and long can be used for digit map timers. Cf. earlier
comment on the use of multiple timer symbols in digit maps, this is
inconsistent with the digit map algorithm specified in Section 7.1.3.
Proposal:       It is recommended to replace the timer symbols "S" and "L" with a
single timer symbol "T" and rely on the algorithm specified in Section
7.1.3. This will furthermore remove the current grammar ambiguity that
exists for the strings "S0", "S1", "S2", and "S3" (MFSig or a short timer
followed by a digit).

v13 Status:     OPEN. Note that Section 7.1.14 now specifies that "S0" etc. are
not valid digit map symbols thereby removing the above ambiguity, but the
digit map grammar in Annex A.3 has not been modified.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:17:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10659
	for ; Tue, 25 Jan 2000 19:17:56 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A3C11C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:15:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8378 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:13:03 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3400F180@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:13:03
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA00930
          for ; Tue, 25 Jan 2000 16:14:44
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152958.00a81280@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:05:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Command Atomicity
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        8
Category:       Technical, Editorial
Issue:          It is unclear if commands are atomic or not. More specifically, if
a command contains signals, events or digit map descriptors, will they
still be applied if the command fails ? If not, should the state of the
termination be reset (i.e. clear the signals, events, digit map named in
the command that has failed, as in MGCP 0.1) or maintained (i.e. as if the
command is not received, as in MGCP 1.0) ?
Proposal:       It is recommended that commands are atomic so that failed
commands leave the gateway in a well known state. It is furthermore
proposed, that a response descriptor should be added to the responses so
that if a command fails, the gateway can provide more information to the
MGC, rather than just an error code, e.g. for redirection.

v13 Status:     OPEN. No relevant text changed.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:17:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10663
	for ; Tue, 25 Jan 2000 19:17:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A8ACE00@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:15:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8383 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:13:05 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.352D6390@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:13:05
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA00939
          for ; Tue, 25 Jan 2000 16:14:47
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152756.00be7140@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:05:29 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Embedded Events/Signals Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.9, third paragraph from bottom
Category:       Technical
Issue:          The draft text specifies that "An Action can include an Embedded
Signals descriptor and/or an Embedded Events Descriptor which, if present,
replaces the current Signals/Events descriptor when the event is detected".
The paragraph does not define what happens with a partially matched digit
map when an Embedded Events Descriptor is activated. For example, lets say
digits "1,2,3" were accumulated according to digit map A, and the embedded
Events Descriptor then accumulates digits according to digit map B, how
does digit map matching proceed ?
Proposal:       It is recommended, that the current dial string is cleared, and
that digit map match should be reset when an embedded Events Descriptor is
activated.

v13 Status:     OPEN. No significant text change has occurred.



Section:        7.2.7, last line
Category:       Technical
Issue:          The draft text specifies that "The events in the list must have
been requested via the triggering EventsDescriptor". This implies that an
embedded EventsDescriptor will prevent previously detected events from
being reported. For example, if an "off-hook" event is used to trigger a
dial-tone, and a request for another set of events through an embedded
events descriptor, it will not be possible to report the off-hook event.
Proposal:       It is suggested that the text is modified to allow reporting of
events triggered by both the surrounding and the embedded EventsDescriptor.


v13 Status:     OPEN. No relevant text has been changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:17:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10671
	for ; Tue, 25 Jan 2000 19:17:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7ACD7C50@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:15:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8388 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:13:07 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.36680670@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:13:07
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA00945
          for ; Tue, 25 Jan 2000 16:14:49
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151656.00a81f00@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:05:19 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Error Codes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.9, second bullet in bullet list
Category:       Technical
Issue:          The draft text specifies that "The notification shall contain error
code 518 (event buffer full)", however a Notify command cannot contain an
error code.
Proposal:       It is recommended that error code 518 is deleted from the list of
error codes, and an "event buffer full" event is defined instead.

v13 Status:     Closed. Removed as part of extensive rewrite of event
processing.  This rewrite needs further review.



Section:        7.3, error code list
Category:       Technical
Issue:          The draft text includes error code 518 for "event buffer full",
however as mentioned earlier, a Notify command does not contain an error
code, and error code 518 should consequently be removed.
Proposal:       It is recommend to remove error code 518 (may consider adding an
"event buffer full" event).

v13 Status:     OPEN. No relevant text changed.


Section:        12.1
Category:       Technical
Issue:          The draft text specifies, that packages contains properties,
events, signals, statistics and procedures. However, when new properties
and signals are defined for a package, it may be beneficial to allow for
package specific error codes to be defined as well. For example, if a
package defines support for MF trunks, it would be beneficial to be able to
communicate specific MF trunk error events when they occur.
Proposal:       It is recommended that Packages may also define new error codes.

v13 Status:     OPEN. No text changed.



Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:17:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10681
	for ; Tue, 25 Jan 2000 19:17:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B1051B0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:15:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8393 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:13:10 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.37D021F0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:13:10
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA00963
          for ; Tue, 25 Jan 2000 16:14:51
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000124151435.00be1630@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:07:19 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Events/Signal Descriptor in Stream Descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA10681

Section:        7.1.6, first line
Category:       Editorial
Issue:          The draft text specifies that “These parameters [for Stream 
Descriptor] are structured into five descriptors: …, a signals descriptor 
and an events descriptor.”, however the signals and events descriptor are 
shown as descriptors independent of the Stream Descriptor in subsequent 
command definitions.
Proposal:       Remove mention of signals and events descriptor.

v13 Status:     CLOSED.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:17:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10693
	for ; Tue, 25 Jan 2000 19:17:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7B530000@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:15:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8398 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:13:14 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3A5175A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:13:14
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA00982
          for ; Tue, 25 Jan 2000 16:14:54
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151223.00b648f0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:10:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Extensions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        N/A
Category:       Open Issue
Issue:          The draft text currently has a number of places where extensions
are permitted by prefixing a token with "X-", however extension
commands  are currently not supported. This issue was identified by the
IETF editor but has not yet been resolved (issue 6).
Discussion:             A continuation of the discussion that has occurred on the
Megaco mailing list so far is needed in order to resolve the issue.

v13 Status:             Extension descriptors have also been removed from 6.2.4.
Extension descriptors and commands should be allowed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:46:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11496
	for ; Tue, 25 Jan 2000 19:46:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B8E4930@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:44:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8471 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:43:01 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63550B70@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:43:01
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA11373
          for ; Tue, 25 Jan 2000 16:44:41
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124153614.00b156a0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:33:42 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Failover
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        11.3, second paragraph
Category:       Editorial
Issue:          The draft text specifies that "Upon failover, the Primary MG sends
a ServiceChange command with a "Failover" method and a "MG Impending
Failure" reasons", however the "Failover" method is not described in
Section 7.2.8 on ServiceChange.
Proposal:       It is recommended that definition of the "Failover" method in
accordance with the text in Section 11.3 is added to Section 7.2.8.

v13 Status:     CLOSED. Failover method added in Section 7.2.8


Section:        11.4,
Category:       Open Issue
Issue:          The draft text does not specify what the MG does if it exhausts its
list of MGC's to try. This is a rather serious omission.
Discussion:     It is strongly recommended that additional work to define this
behaviour is done, and in a way that will ensure that failed MGC's will not
be swamped when they become reachable again (cf. Annex D.1.6).

v13 Status:     OPEN. No text changed.


Section:        11.4,
Category:       Editorial
Issue:          The draft text specifies that "It sends a ServiceChange command
with a "Failover" method and a "MG Impending Failure" reason", however the
"Failover" method is not described in Section 7.2.8 on ServiceChange.
Proposal:       It is recommended that definition of the "Failover" method in
accordance with the text in Section 11.4 is added to Section 7.2.8.

v13 Status:     CLOSED. Failover method added in Section 7.2.8


Section:        11.4, third paragraph
Category:       Technical
Issue:          The draft text specifies that "Accordingly, commands in progress
continue, transaction replies are sent to the new MGC, and the MG should
expect outstanding transaction replies from the new MGC". It is not clear
if messages are directed to the new MGC prior to the handoff being
confirmed by a new MGC or not. Also, it is not defined where retransmitted
transactionrequests are to be sent when a handover occurs until Annex
D.1.4. In order to support consistent and transparent handoff, the above
must be specified.
Proposal:       It is recommended, that messages are not directed to a new MGC
until that MGC has accepted the handover (it is not clear if this is in
line with specification in Annex D.1.4 or not). It also proposed, that
retransmitted transactionrequests are sent to the new MGC as specified in
Annex D.1.4.

v13 Status:     OPEN. No text changed.


Section:        D.1.4, last paragraph
Category:       Open Issue
Issue:  The draft text specifies that "It is however important that the
maximum delay of retransmissions be bounded. Prior to any retransmission,
it is checked that the time elapsed since the sending of the initial
datagram is no greater than T-MAX. If more than T-MAX time has elapsed, the
MG concludes that the MGC has failed, and it begins its recovery process.
The value T-MAX is related to the LONG- TIMER value; the LONG-TIMER value
is obtained by adding to T-MAX the maximum propagation delay in the
network". Since the recovery procedure is not initiated until T-MAX time
has passed, this implies, that the transaction in question will be lost
when the recovery procedure is initiated. This furthermore implies, that
transparent failover is not supported by the protocol which again will lead
to a degraded level of service

Proposal:       It is recommended, that work on a recovery procedure that will
enable transparent failover is done and included in the specification.

v13 Status:     OPEN. No text changed.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 19:46:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11498
	for ; Tue, 25 Jan 2000 19:46:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8BDD0570@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:44:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8476 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:43:04 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6525FAE0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:43:04
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA11416
          for ; Tue, 25 Jan 2000 16:44:45
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151639.00a65100@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:43:03 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Keep Active
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.9, "Event Actions" table
Category:       Technical
Issue:          The draft text specifies that "KeepActive:      As Notify, but
production of signals continues (if any signals were active)".The above
definition is overly restrictive in that it prevents events from being
accumulated (either with or without digit map) and at the same time keeping
a signal active. For example an IVR application accumulating a string of
user input and playing an announcement until the entire string is
accumulated cannot be supported with the above behaviour.
Proposal:       It is recommended, that "KeepActive" does not generate a "Notify"
and that it becomes possible to specify multiple actions such that
"KeepActive" can be combined with, e.g. "Notify" or "AccumulateByDigitMap"
depending on the particular application.

v13 Status:     OPEN. Event actions table has been removed and extensive
modification of entire event processing taken place.


Section:        7.1.9
Category:       Technical
Issue:          The draft text specifies that "When KeepActive is specified as the
event action, the media gateway shall send a Notify message to the
controller upon detection of the event. Furthermore, the controller shall
not interrupt any signals active on the Termination on which the event is
detected" The above definition is overly restrictive in that it prevents
events from being accumulated (either with or without digit map) and at the
same time keeping a signal active. For example an IVR application
accumulating a string of user input and playing an announcement until the
entire string is accumulated cannot be supported with the above behaviour.
Proposal:       It is recommended, that "KeepActive" does not generate a "Notify"
and that it becomes possible to specify multiple actions such that
"KeepActive" can be combined with, e.g. "Notify" or "AccumulateByDigitMap"
depending on the particular application.

v13 Status:     OPEN. Extensive modifications of event handling has taken
place. Events now always reported immediately on detection.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:02:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11885
	for ; Tue, 25 Jan 2000 20:02:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5D9EF90@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:59:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8510 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:57:59 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7AB3F220@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:57:59
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA15833
          for ; Tue, 25 Jan 2000 16:59:41
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151516.00bec4d0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:46:54 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Local negotiation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.8, second paragraph
Category:       Open Issue
Issue:          The draft text specifies that "Local is the capability of the local
MG and is typically sent from MG to MGC, and subsequently used as part of a
capability negotiation between two MGCs. Remote contains the parameters
describing the flows the remote MG will send/receive, is typically sent
from MGC to MG, and is the result of the capability negotiation". The
details of this negotiation as well as how it interacts with
LocalControlDescriptor and the network package defined in Annex E.9 is
unclear and needs further clarification. In particular, it is not clear:

*       that the specification adequately supports media streams with asymmetric
send and receive capabilities.
*       when negotiated media resources are reserved and they are available for use
It should be noted, that this particular issue has been the subject of much
debate on the IETF Megaco mailing list since the white contribution was
developed, and that at time of writing, no resolution had been found.
Discussion:             Given the fact, that solving this issue is at the heart of the
very purpose of the protocol, it is recommended that additional work to
develop a solution that satisfies the protocol requirements [1] in this
area is done.

v13 Status:             Modified. INADEQUATE. Above text has been removed and replaced
with extensive new text, incl. description of "Reserve" parameter in
Section 7.1.7 which provides for:
*       Return all alternatives supported and currently capable, and reserve
sufficient resources for any one of those.
*       Return one alternative, and reserve sufficient resources for that one.
In addition to these two options, a third option is proposed:
*       Return all alternatives supported and currently capable, but only reserve
sufficient resources for one alternative selected.
This will allow each endpoint to learn the capabilities of the other
without requiring that simultaneous support for each alternative. This may
be required when codecs (or other associated resources, e.g. external
resource reservation) can not be activated nearly instantaneously.
Also, how does this interwork with SIP, etc., i.e. other protocols that use
SDP ? For example, it does not seem to be legal to only support a subset of
the codecs listed in an "m=" line which is somewhat problematic.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:02:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11895
	for ; Tue, 25 Jan 2000 20:02:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A62884C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:59:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8515 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:58:03 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7D13DB20@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:58:03
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA15842
          for ; Tue, 25 Jan 2000 16:59:43
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152349.00c03d60@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:49:30 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Multiplex Descriptor in Add
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.2.1, third paragraph from bottom
Category:       Technical
Issue:          The draft text specifies that "if a Multiplex Descriptor is
present in an Add command and lists any Terminations that are not currently
in the Context, such Terminations are added to the context as if individual
Add commands listing the Terminations were invoked". However it is not
specified how errors encountered when adding such terminations are handled
(normally, when wildcards are used, a response for each termination matched
by the wildcard would be returned).
Proposal:       It is proposed that the command fails and an error code is
defined for this case is defined.

v13 Status:     OPEN. No relevant text changed.

Section:        D.1.5, item number 4
Category:       Editorial
Issue:          The draft text does not point out the side-effect of a an
Add command with a Mux-descriptor naming terminations not presently in the
context. Such commands essentially operate as wild-carded Add commands and
should consequently be mentioned as well.
Proposal:       It is suggested that the following sentence is added to the
end of rule 4: "This includes Add commands with a Mux-descriptor where the
terminations in the Mux-descriptor are covered by the wild-carding in the
Subtract command"

v13 Status:     OPEN. No text changed.



Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:02:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11905
	for ; Tue, 25 Jan 2000 20:02:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A66B5A20@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:59:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8520 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:58:10 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.814E5080@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:58:10
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA15861
          for ; Tue, 25 Jan 2000 16:59:51
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124155255.00bc5d90@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:52:01 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16: Preconditions on commands
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        D.1
Category:       Technical
Issue:          The current draft text does not support the concept of
preconditions that must be established in order for a command to be
successful. For example, the MGC and the MG can get out of synch on the
hook state. Consider a MG that just cold-started. Before the gateway
generates a restart ServiceChange, the user picks up the handset. The
gateway detects the off-hook transition, but since it does not have an
EventsDescriptor, it does not generate Notify. Soon after, the gateway
generates a restart ServiceChange. After the MGC receives the message, it
generates a Modify to the gateway to request off-hook detection. However,
since the off-hook transition has happened, the gateway does not generate
Notify. Since the gateway does not play any tone to the user, the user
hangs up the phone. Since the MGC has not requested the gateway to detect
on-hook transition, the gateway does not generate Notify either. If
preconditions were defined and supported, e.g. to require that a request
for off-hook detection would only succeed if the line state was currently
on-hook, such errors could be avoided.
Proposal:       It is strongly recommended, that preconditions as described above
are added to the draft.

v13 Status:     OPEN. No relevant text changed.

Note that this topic has already generated discussion on the list.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:02:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11915
	for ; Tue, 25 Jan 2000 20:02:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6AE0870@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:59:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8525 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:58:13 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.833252C0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:58:13
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA15876
          for ; Tue, 25 Jan 2000 16:59:54
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124155834.00abd520@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:51:24 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16: Provisional Response timers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        D.1.4
Category:       Technical
Issue:          The draft text specifies that receipt of a provisional response
will imply a switch to a longer repetition timer for the transaction.
However, there is no other reliability mechanism in place to detect the
loss of the final response for that transaction, and consequently a lost
final response may not be detected for a while (depends on the longer
repetition timer). This leads to suboptimal behaviour of the protocol with
unnecessary long time-outs.
Proposal:       It is proposed, that a final response issued after a provisional
response requires an immediate confirmation to enable rapid detection of a
lost final response. Since the provisional response itself may be lost,
this implies that the final response should include an indication that a
response acknowledgement is required (immediately).

v13 Status:     OPEN. No relevant text changed.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:02:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11925
	for ; Tue, 25 Jan 2000 20:02:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6F0DDD0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:59:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8530 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 19:58:16 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8484EA70@standards.nortelnetworks.com>; Tue, 25 Jan 2000 19:58:15
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA15906
          for ; Tue, 25 Jan 2000 16:59:57
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124152856.00c01670@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:55:16 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16: Service Change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.2.8, third last paragraph
Category:       Editorial
Issue:          The draft text specifies that "The ServiceChangeMethod
shall be "forced" for this usage". This is inconsistent with the
description in Section 11.2 which specified a ServiceChangeMethod of
"Restart".
Proposal:       It is recommended that the above text is modified to use a
ServiceChangeMethod of "Restart" instead.

v13 Status:     CLOSED. Text has been modified.


Section:        11.2
Category:       Technical
Issue:          When a gateway starts, it generates a restart ServiceChange
to the MGC. If the MGC's response to the ServiceChange is lost while a
later command is received by the gateway, how this command is handled is
not specified in the draft text.

Proposal:       It is recommended that the gateway will return an error.

v13 Status:     OPEN. No text changed.


Section:        11.2
Category:       Technical
Issue:          The draft text specifies that "If the MGC accepts the MG,
it will send a Transaction Accept, with the MGCIdToTry set to itself. If
the MG receives an MGCIDToTry not equal to the MGC it contacted, it send a
ServiceChange to the MGC specified in the MGCIdToTry". It is inconsistent
to on one hand accept the transaction as successful, yet on the other hand
require the MG to examine the MGCIdToTry returned to determine if the
registration really was successful or not. Examination of the syntax
reveals that this is part of a larger problem where unsuccessful
transactions, actions and commands are not able to return any other
information than an ErrorDescriptor which can only contain an error code
and text.
Proposal:       It is recommended that the above procedure is replaced by
return of an error code and another MGCIdToTry if the registration did not
complete. Furthermore, it is recommended that ErrorDescriptors are extended
to allow return of other information (essentially CommandReply) than only
an error code and text.

v13 Status:     OPEN. No text changed









Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:17:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12122
	for ; Tue, 25 Jan 2000 20:17:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C506AB90@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:14:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8648 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:13:00 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.93C98980@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:13:00
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA19998
          for ; Tue, 25 Jan 2000 17:14:41
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124153947.00b64ba0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 19:58:49 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Signals Operation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.10, fourth paragraph, first bullet.
Category:       Technical, Open Issue
Issue:          The draft text defines on/off signals "the signal lasts until it is
turned off", however this definition is not clear. Specifically, it is not
clear if an on/off signal is turned off by not being included in a
subsequent SignalsDescriptor or if it is turned off by some explicit
action. In the latter case, syntax is missing leading one to believe that
the former definition is intended. The former definition on the other hand
is somewhat problematic and overlaps the definition of time-out signals
with an indefinite duration. Consider for instance a "visual message
waiting indicator" defined as an on/off signal. Unless the signal is
included in all subsequent SignalsDescritpors, the indicator will be turned
off. The on/off signal type would be more useful (and not a duplicate of
timeout) if this was not the case.
Also, it should be noted, that the more general topic of signal types and
the details of their operation has been the subject of much debate on the
IETF Megaco mailing list since the white contribution was developed, and
that at time of writing, no resolution had been found.

Proposal:       It is recommended that the definition of on/off is clarified in
accordance with the above and the missing syntax added.

v13 Status:     OPEN. No substantial change has been made.


Section:        7.1.10, fourth paragraph, second bullet
Category:       Technical
Issue:          The draft text defines timeout signals as "the signal lasts until
it is turned off or a specific period of time elapses", however there is no
mechanism specified for informing the MGC when that specific period of time
has elapsed and thus the signal has ended. The MGC may therefore be unable
to determine if a given signal is playing in an MG or not. An example where
this is needed is outpulsing with MF Feature Group D trunks where multiple
digit strings (address and caller id) need to be outpulsed. MGC needs to
know when outpulsing of the first string of digits has occurred before
requesting out-pulsing of the next string.). Another example is a signal
activated through an external event such as user input (by use of an
embedded signals descriptor).

Proposal:       It is strongly recommended that a mechanism for notifying the MGC
upon timeout signal completion is added, e.g. in the form of an event
("operation complete"). Furthermore, it should be considered to add another
event that would allow the MGC to be informed if generation of the signal
fails for some reason (e.g. "operation failure"). It should be noted, that
this may happen in the middle of the signals defined duration.

v13 Status:     OPEN. No substantial change has been made.


Section:                12.1.4
Category:       Technical, Open Issue
Issue:          The draft text mentions SignalType CN (Continue), however this
SignalType is not defined in Section 7.1.10 on Signals Descriptor.
Also, it should be noted, that the more general topic of signal types and
the details of their operation has been the subject of much debate on the
IETF Megaco mailing list since the white contribution was developed, and
that at time of writing, no resolution had been found.
Proposal:       It is proposed that SignalType CN is removed from the text.

v13 Status:     OPEN. No text changed.


Section:        12.1.4
Category:       Technical, Open Issue
Issue:          The draft text specifies that "Signals that would be played with
SignalType BR should have a default duration"
Again, it should be noted, that the more general topic of signal types and
the details of their operation has been the subject of much debate on the
IETF Megaco mailing list since the white contribution was developed, and
that at time of writing, no resolution had been found.
Proposal:       It is proposed that similar text is added as for signals of
SignalType TO.

v13 Status:     OPEN. No text changed.



Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:17:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12129
	for ; Tue, 25 Jan 2000 20:17:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5470FF0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:14:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8653 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:13:03 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.956D2760@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:13:03
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA20020
          for ; Tue, 25 Jan 2000 17:14:44
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000121201316.00adaf00@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 20:02:50 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Streams
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        7.1.4, second paragraph
Category:       Technical
Issue:          The draft text specifies that "A stream is identified by a
StreamID", however there is no uniqueness requirement on the StreamID which
may lead to inconsistent behaviour.
Proposal:       Since terminations, and thereby streams, may be moved between
different context, it is recommended that StreamIDs are defined to be
unique within a MG.

v13 Status:     OPEN. No new text.


Section:        7.1.7, third paragraph
Category:       Technical
Issue:          The draft text specifies that "Mode set to delete is used to remove
a stream from a termination". There is no mention of how to add a stream
which would seem logical to be able to if you can delete a stream.
Proposal:       It is recommended that text describing how streams are added is
included.

v13 Status:             OPEN. No text added.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:17:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12141
	for ; Tue, 25 Jan 2000 20:17:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C589E550@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:14:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8658 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:13:05 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.96D060E0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:13:05
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA20037
          for ; Tue, 25 Jan 2000 17:14:47
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Message-ID:  <4.2.2.20000124155401.00be7d40@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 20:06:39 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Transaction ID uniqueness
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA12141

Section:        D.1.1, second paragraph
Category:       Technical, Editorial
Issue:          The draft text specifies that “The transaction identifiers of 
incoming messages are compared to the transaction identifiers of the recent 
responses”. This is inconsistent with Section 8.1.1 where transaction 
identifiers are defined to only be unique within the scope of a given 
sender. Transaction identifiers should indeed be unique within the scope of 
a given sender to avoid having to synchronize transaction identifiers 
between MGC’s, e.g. when handoff or failover is performed.
Proposal:       It is proposed that the text is modified to be consistent with 
Section 8.1.1.

v13 Status:     OPEN. No text changed.


Section:        D.1.1, second paragraph
Category:       Technical, Editorial
Issue:          The draft text specifies that “The remaining messages will be 
compared to the list of current transactions. If a match is found, 
indicating a duplicate transaction, the entity does not execute the 
transaction, which is simply ignored”. The above behaviour is sub-optimal 
and will lead to unnecessary retransmissions and adjustment of 
retransmission timers for subsequent transmissions. It is furthermore 
inconsistent with the description in Annex D.1.4.
Proposal:       It is proposed that a “TransActionPending” response is returned 
instead.

v13 Status:     OPEN. No text changed.


Section:        D.1.1, last paragraph.
Category:       Technical, Editorial
Issue:          The draft text specifies that “For transactions that are 
acknowledged through this parameter, the MG shall keep a copy of the 
transaction-id for LONG_TIMER seconds after the response is issued, in 
order to detect and ignore duplicate copies of the transaction response”. 
The sentence is incorrect as the purpose of the keeping the transaction-id 
(but not the response) at the MG is to recognize duplicate transaction 
requests which can then be ignored with it is known that the requestor 
already received the response.
Proposal:       It is recommended that “transaction response” is changed to 
“transaction request” in the above sentence. Furthermore, it is recommended 
the “the MG” is changed to “the MG (or MGC)” as the behaviour applies to both.

v13 Status:     OPEN. No text changed.


Section:        D.1.2, first paragraph, last line
Category:       Technical, Editorial
Issue:          The draft text specifies that “MGs can simply detect duplicate 
transactions by looking at the transaction identifier only”. This is 
inconsistent with the “sender uniqueness only” requirement on transaction 
identifiers in Section 8.1.1, which implied that MGs have to look at the 
combination of “mId” and transaction identifier to identify a duplicate 
transaction.

Proposal:       It is recommended that the text is modified to be consistent with 
Section 8.1.1, i.e. that the combination of transaction identifier and mId 
identifies a given transaction.

v13 Status:     OPEN. No text changed.


Section:        D.1.2, fourth paragraph
Category:       Technical
Issue:          The draft text specifies that “The entity shall retain the union of 
the “confirmed transaction-id ranges” received in recent messages”. This is 
inaccurate. More specifically, a given “confirmed transaction-id range” is 
valid for LONG-TIMER seconds.
Proposal:       It is proposed that the text is modified to reflect the above.

v13 Status:     OPEN. No text changed.


Section:        D.1.4, fourth paragraph
Category:       Technical
Issue:          The draft text specifies that “The transaction identifiers of 
incoming transactions are compared…”. The paragraph duplicates Section 
D.1.1 and contains the same problem of ignoring the “sender uniqueness 
only” requirement on transaction identifiers as well as not issuing a 
provisional response when a duplicate request for an in-progress transaction.
Proposal:       It is proposed that the paragraph is either removed or the text 
modified to reflect the “sender uniqueness requirement” and sending of a 
provisional response.

v13 Status:     OPEN. No text changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.          	
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:17:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12152
	for ; Tue, 25 Jan 2000 20:17:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C5CC93A0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:14:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8663 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:13:07 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.981711B0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:13:07
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA20042
          for ; Tue, 25 Jan 2000 17:14:49
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124153136.00aaa890@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 20:07:43 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Virtual MG & Root
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        11.1, second last paragraph
Category:       Technical/Editorial
Issue:          The draft text specifies that "Each virtual MG has its own Root
Termination" but "ServiceChange may only be applied to the Root by the
Master MGC". The two statements seem to be inconsistent as the purpose of
the virtual MG (and thereby the root termination for that virtual MG) is to
allow the MGC for the virtual MG to control that virtual MG.
Proposal:       It is proposed, that the last sentence is removed since each
virtual MG has its own Root termination.

v13 Status:     OPEN. No relevant text changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:21:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12194
	for ; Tue, 25 Jan 2000 20:21:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.572DD4D0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:18:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8708 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:18:21 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.52F5A960@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:18:21
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA21388
          for ; Tue, 25 Jan 2000 17:20:02
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124151134.00b567c0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 20:17:37 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Annex E comments
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        E.1.3, E.3.3, E.5.3, E.7.3
Category:       Technical, Editorial
Issue:          The draft text does not follow the package format specified in
Section 12.1.4. More specifically, neither SignalType nor Duration is
specified.
Proposal:       It is recommended that SignalType and Duration are specified.

v13 Status:     OPEN. No text changed.


Section:        E.4
Category:       Editorial, Technical
Issue:          The draft text only specifies toneID's, not EventID's, thereby
violating the package format specified in Section 12.1.3.
Proposal:       It is recommended that eventIDs are defined for the DTMF tones as
well as the current toneIDs.

v13 Status:     OPEN. No relevant text changed.


Section:        E.4
Category:       Technical
Issue:          The draft text specifies that "Support of dA-dD is optional".
Having optional events in a package tends to defeat the purpose of packages
in the first place.
Proposal:       It is recommended that either support for the signals become
mandatory or they are provided in a separate package.

v13 Status:     OPEN. No relevant text changed.


Section:        E.6
Category:       Technical, Editorial
Issue:          The draft text only specifies toneID's, not EventID's, thereby
violating the package format specified in Section 12.1.3.
Proposal:       It is recommended that eventIDs are defined for the Call Progress
Tones as well as the current toneIDs.

v13 Status:     OPEN. No relevant text changed.


Section:        E.8
Category:       Technical
Issue:          The draft text specifies that the possible values for the signals
are "q724" and that the MG figures out whether a 2-wire or 4-wire
continuity test is to be performed on the trunk in question. First of all,
it is unclear how the MG determines precisely what continuity test variant
to perform unless it is assumed that the MG is provisioned with this
information, however this should not be a requirement. Secondly, national
variants of continuity test procedures exist, and considering the package
is a "basic continuity package" it should be possible to use this package
without requiring support for Q.724 continuity test.
Proposal:       It is recommended, that the possible test values are not
specified in this basic package, but that extension packages define this
packages, similarly to the "tone generator" and "tone detection" packages
defined in Annex E.1 and E.2

v13 Status:     OPEN. No relevant text changed.



Section:        E.9
Category:       Open Issue
Issue:          Cf. comment to Section 7.1.8 on "Local" and "Remote" as well as
ongoing list discussion, it is unclear what the status of this package
should be. Furthermore, it does not seem like the package supports
specification of asymmetric codecs. It is also not clear, how multiple
independent yet comprehensive codec specifications can be supported by the
package.
It should be noted, that this particular issue has been the subject of much
debate on the IETF Megaco mailing list since the white contribution was
developed, and that at time of writing, no resolution had been found.
Proposal:       Given the fact, that solving this issue is at the heart of the
very purpose of the protocol, it is recommended that additional work to
develop a solution that satisfies the protocol requirements [1] in this
area is done.

v13 Status:     CLOSED ? Most of the package now removed. If the v13 solution
on Local/Remote is accepted, this particular issue seems to be closed.


Section:        E.11.1
Category:       Technical
Issue:          The draft text specifies that "silence suppression" is a property
of the DS0 package. However silence suppression relates to the encoding
method and as such should be a property of each packet based termination.
For example, if a three-way call is established with one DS0 termination,
and two RTP terminations, it is conceivable that one of the RTP
terminations would like to use silence suppression while the other would
not (or cannot for that matter as not all codecs support silence
suppression).
Proposal:       It is recommended that the "silence suppression" property is
moved from the DS0 package to the "network package"

v13 Status:     SEMI-OPEN. Silence suppression has been removed, but it has not
been added anywhere else (except for Annex C.1 which defines it as a
General Media Attribute).



Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 20:21:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12204
	for ; Tue, 25 Jan 2000 20:21:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.57A28FA0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:18:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8715 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 20:18:24 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.549BB840@standards.nortelnetworks.com>; Tue, 25 Jan 2000 20:18:23
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA21398
          for ; Tue, 25 Jan 2000 17:20:05
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000124154057.00b92da0@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 20:18:52 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  ATM encoding in SDP
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        B
Category:       Open Issue
Issue:          The draft text does not specify how to support ATM bearer
descriptions in SDP, however Annex C has syntax to create ATM bearers for
the binary encoding. This issue was identified by the IETF editor but has
not yet been resolved (issue 11).
Discussion:             A continuation of the discussion that has occurred on the
Megaco mailing list so far is needed in order to resolve the issue.

v13 Status:     OPEN. No relevant text has changed.

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Jan 25 21:32:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13195
	for ; Tue, 25 Jan 2000 21:32:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D5D1F10@standards.nortelnetworks.com>; Tue, 25 Jan 2000 21:29:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8953 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 25 Jan 2000 21:27:55 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.0B172DD0@standards.nortelnetworks.com>; Tue, 25 Jan 2000 21:27:55
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id SAA06111
          for ; Tue, 25 Jan 2000 18:29:38
          -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000125211259.00b4aa90@dogwood.cisco.com>
Date:         Tue, 25 Jan 2000 21:13:57 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Cisco SG16:  Comment on E.3.4
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section:        E.3.4
Category:       Editorial
Issue:          The chosen values for signal IDs are somewhat confusing
considering
the fact that another representation is used in digit maps.
Proposal:       It is recommended that, at a minimum, it should be
clarified that
the signal ID values specified here are translated to another
representation prior to attempting a match in a digit map.
Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 05:35:51 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00882
	for ; Wed, 26 Jan 2000 05:35:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF4D5E60@standards.nortelnetworks.com>; Wed, 26 Jan 2000 5:33:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 05:32:03 -0500
Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.AD02C3F0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 5:32:03
          -0500
Received: from oleane  (dyn-1-1-250.Vin.dialup.oleane.fr [195.25.4.250])  by
          smtp2.cluster.oleane.net  with SMTP id LAA41950; Wed, 26 Jan 2000
          11:31:40 +0100 (CET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0083_01BF67F0.7F6990E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID:  <008601bf67e8$1fef18e0$0401a8c0@oleane.com>
Date:         Wed, 26 Jan 2000 11:28:41 +0100
Reply-To: Peter Lewis 
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Peter Lewis 
Subject:      SIP 2000 Call for Paper
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0083_01BF67F0.7F6990E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

SIP 2000: Beyond H.323? A scientific committe composed of the most =
eminent experts in this technology will review the abstracts submitted =
from the Call For Papers:
http://www.upperside.fr/basip.htm
Take a look at the exhibition list.

------=_NextPart_000_0083_01BF67F0.7F6990E0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









        

        SIP 2000: Beyond H.323? A scientific =
committe=20
composed of the most eminent experts in this technology will review the=20
abstracts submitted from the Call For Papers:
        

        http://www.upperside.fr/basip.=
htm
        

        Take a look at the exhibition=20
list.
        

------=_NextPart_000_0083_01BF67F0.7F6990E0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 08:42:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04014
	for ; Wed, 26 Jan 2000 08:42:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.046698A0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 8:40:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9586 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 08:39:04 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CD1BA0C0@standards.nortelnetworks.com>; Wed, 26 Jan 2000
          8:39:04 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 26 Jan 2000 07:40:44 -0600
Received: from zrchb213.us.nortel.com by zmers013; Wed, 26 Jan 2000 08:40:24
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Wed, 26 Jan 2000 07:40:23 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Wed, 26 Jan 2000 07:40:21 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Interesting Times
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Due to some sort of link configuration failure at our local ISP, I'm not
getting my mail from the Megaco list.  I can see it pile up via the Web
interface.  I'll just have to do my best to moderate discussion via
screen-scraping.

Interesting times indeed.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 10:09:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05195
	for ; Wed, 26 Jan 2000 10:09:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B619720@standards.nortelnetworks.com>; Wed, 26 Jan 2000 10:06:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9649 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 10:05:27 -0500
Received: from mail.teledata.co.il (194.90.46.238) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.78AFAF80@standards.nortelnetworks.com>; Wed, 26 Jan 2000
          9:55:26 -0500
Received: by mail2.teledata.co.il with Internet Mail Service (5.5.2448.0) id
          ; Wed, 26 Jan 2000 16:56:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Message-ID:  <00BBC23881EAD211A9CF00805FA9663401C30BA0@mail2.teledata.co.il>
Date:         Wed, 26 Jan 2000 16:56:36 +0200
Reply-To: Arik Klein 
Sender: "Media Gateway Control (megaco)"
              
From: Arik Klein 
Subject:      MG to MGC database coordination using SNMP
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

As I understand so far, H.248 intends to provide whatever is necessary for
the MGC to learn the MG's terminations structure and properties (using
AuditCapabilities).
Now, assuming that we are talking about a heavy MG, where we have an
hierarchical tree of terminations, wouldn't it be better to use SNMP just
for the database learning by the MGC ?
Is this a new idea or was it raised on the list and rejected for some reason
?

Thanks,
Arik


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 13:08:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08194
	for ; Wed, 26 Jan 2000 13:08:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.177411A0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 13:06:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9884 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 13:04:20 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DBF35F50@standards.nortelnetworks.com>; Wed, 26 Jan 2000
          13:04:20 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 26 Jan 2000 12:05:15 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 26
          Jan 2000 13:04:57 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Wed, 26 Jan 2000 13:04:57 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Wed, 26 Jan 2000 13:04:49 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Root Package
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'd suggest the following resolution: Global properties can be set only by
provisioning.  A fallback is to say they require a Modify applied to the
ROOT termination, but I'd leave that to v2 and more experience.


                    From:         Chip Sharp 
                    Subject:      Root Package
                    Content-Type: text/plain; charset="iso-8859-1";
format=flowed

                    Section:        6.2.3
                    Category:       Open Issue
                    Issue:          The draft text does not address packages
adding properties to root.
                    This issue was identified by the IETF editor but has not
yet been resolved
                    (issue 3). The issue is, that some packages need a
property which is the
                    same for all terminations that implement the package.
Quantify of is an
                    example, or bandwidth perhaps.
                    Discussion:             A continuation of the discussion
that has occurred on the
                    Megaco mailing list so far is needed in order to resolve
the issue.

                    v13 Status:             Partially CLOSED ? Section 6.2.4
states that "A property may
                    be declared as "Global" which has a single value shared
by all terminations
                    realizing the package". Not clear how this value is
synchronized between
                    terminations as there are no rules for how and when
updates can be made
                    (e.g. by multiple terminations simultaneously ?).  There
are no procedures
                    in Section 12 on how to declare a value as Global.
                    Suggested Text is welcome.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:10:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11504
	for ; Wed, 26 Jan 2000 16:10:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87EE6F70@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:08:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9977 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:06:44 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F15F2690@standards.nortelnetworks.com>; Wed, 26 Jan 2000 15:56:44
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA24830; Wed, 26 Jan
          2000 15:58:22 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA22759; Wed, 26 Jan
          2000 15:58:25 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 15:55:23 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208824@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 15:58:23 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: DTMF and Signals descriptor
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Right, but are you in agreement that signal lists don't have
signal type or duration parameters?

Brian

> -----Original Message-----
> From: John Segers [mailto:jsegers@LUCENT.COM]
> Sent: Tuesday, January 25, 2000 8:22 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: DTMF and Signals descriptor
>
>
> "Rosen, Brian" wrote:
> >
> > This doesn't make sense to me; why would you be able to change the
> > SignalType but not the duration.  If you want signal lists
> to not have
> > duration, they should not have signal type.  That is okay
> with me, the
> > signal type is then always defined by the last signal.
>
> Not by the last signal.  It's a little more complicated:
> - only the last in the sequence can be on/off.  If so, the type of the
> list is on/off;
> - if the last in the sequence is not on/off, and there is an
> element in
> the sequence with type timout, the type of the list is timeout;
> - if all elements of the sequence are type brief, then the
> list is type
> brief.
>
> John
>
> > Brian
> >
> > > -----Original Message-----
> > > From: John Segers [mailto:jsegers@LUCENT.COM]
> > > Sent: Tuesday, January 25, 2000 3:16 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Re: DTMF and Signals descriptor
> > >
> > >
> > > Jo, Brian,
> > >
> > > I changed the occurrence of "sequential play list" to
> > > "sequential signal
> > > list".
> > >
> > > It doesn't make sense to me to define the duration of a
> seq. signal
> > > list. So in the paragraph on sequential signal lists, I
> propose to add
> > > the following sentence: "The duration of a sequential
> signal list with
> > > type timeout is equal to the sum of the durations of the
> signals it
> > > contains."
> > >
> > > John
> > >
> > > "Rosen, Brian" wrote:
> > > >
> > > > See comments below
> > > >
> > > > > -----Original Message-----
> > > > > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > > > > Sent: Monday, January 24, 2000 5:42 PM
> > > > > To: MEGACO@standards.nortelnetworks.com
> > > > > Subject: DTMF and Signals descriptor
> > > > >
> > > > >
> > > > > Please tell me if I'm correct in assuming that there
> are at least
> > > > > two ways for the MGC to request the MG to signal DTMF
> digits on a
> > > > > physical termination. I also have some V13 comments related to
> > > > > the signal descriptor below.
> > > > >
> > > > > Are both of these correct for dialing '125'?
> > > > >
> > > > > Signals {
> > > > >    dg/pt {
> > > > >       ind=100,         ; interdigit duration
> > > > >       tl=[d1,d2,d5]   ; dtmf digits 125
> > > > >    }
> > > > > }
> > > > > In this case how is the signal duration specified?
> > > > Since the default SignalType for dtmf digits is BRief, the
> > > duration is
> > > > fixed (or provisioned) it could be overriden by using the
> > > duration parameter
> > > >
> > > > to specify something else.  SignalType and Duration are
> > > available for every
> > > > signal.
> > > >
> > > > >
> > > > > or
> > > > >
> > > > > SignalList = 10 {
> > > > >    SignalType=Timeout,
> > > > >    Duration=250,
> > > > >    dg/d1,
> > > > >    dg/d2,
> > > > >    dg/d5
> > > > > }
> > > > Yes
> > > >
> > > > > V13 comments:
> > > > > In 7.1.11 the last sentence of the 1st paragraph refers to
> > > > > "sequential play lists". I assume that is the same as
> "sequential
> > > > > signal lists" so it should be replaced to avoid confusion.
> > > > Yes, we should fix this
> > > >
> > > > >
> > > > > In the ABNF for signalListParm the preceding comments contains
> > > > > the phrase "at most once duration and every signal
> parameter". I
> > > > > understand "at most once duration" but I don't
> understand what is
> > > > > meant to be conveyed by the rest of the phrase.
> > > > I think it means that a parameter to a signal can only
> > > occur once per
> > > > signal instance in the list (but signal can occur more than
> > > once, and
> > > > in each case signal parameters can be included (once).
> > > >
> > > > >
> > > > > In the ABNF for signalListParm if SigSignalType=Timeout is
> > > > > sigDuration required? The description of timeout in 7.1.11
> > > > > implies if there is no duration the signal is played
> until it is
> > > > > turned off. In a signal list this doesn't make sense
> because the
> > > > > first signal in the list would be the only signal played,
> > > > > wouldn't it?
> > > > I don't think we talked about this.  A normal signal has a
> > > default duration
> > > > and if not specified, that is what you use.  A signal list
> > > does not have
> > > > a default duration.  At the moment, I'd say it's an
> error to specify
> > > > SignalType = TimeOut and not specify Duration.
> > > >
> > > > >
> > > > > Thanks for any clarifications!
> > > > > Jo
> > > > >
> > > >
> > > > Brian
> > >
> > > --
> > > John Segers                                  email:
> jsegers@lucent.com
> > > Lucent Technologies
>  Room HE 306
> > > Dept. Forward Looking Work                      phone:
> +31 35 687 4724
> > > P.O. Box 18, 1270 AA  Huizen                      fax:
> +31 35 687 5954
> > >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:12:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11526
	for ; Wed, 26 Jan 2000 16:12:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CFF59D20@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:10:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9978 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:08:51 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.3CFEBD40@standards.nortelnetworks.com>; Wed, 26 Jan 2000 15:58:51
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25088; Wed, 26 Jan
          2000 16:00:34 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA23357; Wed, 26 Jan
          2000 16:00:37 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 15:57:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF683F.F8966F20"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208825@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:00:35 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF683F.F8966F20
Content-Type: text/plain;
        charset="iso-8859-1"

I believe that
    Context=*{Modify=TermId{Audit{})
should return something like
    Context=c11911{Modify=TermId}

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 25, 2000 8:37 AM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Subtract Command with wildcard Termination Name



OK, this is the second comment I've had to this effect -- the other was
received privately.  The one question is whether we want a way to find out
what context a termination is in without subtracting it to find out, in
which case the audit response syntax I suggested might be considered.
Silence means we don't need this additional functiuonality.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Monday, January 24, 2000 10:10 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:        RE: Subtract Command with wildcard Termination Name

        I think this is headed in the wrong direction.  Subtract of
wildcarded contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.

It is also useful in a wildcard Audit, with or without W-.

So I think it is allowed, period.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Monday, January 24, 2000 10:06 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Subtract Command with wildcard Termiantion Name



        Your question has a couple of wider implications.  My first reaction
was to say this was an error, because in principle the MGC can always know
which context a termination is in, through audits if necessary.  Then I
checked out our audit response syntax and realized that the MGC cannot
determine the current context of a termination if it doesn't know it
already.

        I think the answer has to be that we change the production
auditOther to include the context ID.

e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT

        Then the answer to your original question is that it is an error.

                -----Original Message-----
From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
Sent:   Sunday, January 23, 2000 11:56 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Subtract Command with wildcard Termiantion Name

                Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?

                Regards
MadhuBabu


------_=_NextPart_001_01BF683F.F8966F20
Content-Type: text/html;
        charset="iso-8859-1"




RE: Subtract Command with wildcard Termination Name




        I
believe that 
        

           
Context=*{Modify=TermId{Audit{})
        

        should
return something like
        

           
Context=c11911{Modify=TermId}
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Tuesday, January 25, 2000
  8:37 AM
        To: Rosen, Brian;
  megaco@standards.nortelnetworks.com
        Subject: RE: Subtract Command
  with wildcard Termination Name

        
  
        OK, this is the second comment I've
  had to this effect -- the other was received privately.  The one question
  is whether we want a way to find out what context a termination is in without
  subtracting it to find out, in which case the audit response syntax I
  suggested might be considered.  Silence means we don't need this
  additional functiuonality.
        
  
          
    
          -----Original Message----- 
          From:   Rosen, Brian [SMTP:brosen@fore.com] 
          Sent:   Monday, January
    24, 2000 10:10 PM 
          To:     Taylor, Tom-PT [CAR:B904:EXCH];
    MEGACO@standards.nortelnetworks.com 
          Subject:        RE: Subtract Command with wildcard Termination Name
    
          
    
          I think this is headed in the wrong
    direction.  Subtract of wildcarded contextId was explicitly allowed
    for, 
          among other things,
    the response to a ServiceChange with mass out of service operations
    pending. 
          The MGC must
    subtract all calls, and do it in a hurry. 
            
          It is
    also useful in a wildcard Audit, with or without W-. 
            
          So I
    think it is allowed, period. 
           
    
          Brian 
          
    
            
      
            -----Original Message-----
            From: Tom-PT Taylor
      [mailto:taylor@nortelnetworks.com]
            Sent: Monday, January 24, 2000
      10:06 AM
            To: MEGACO@standards.nortelnetworks.com
            Subject: Re:
      Subtract Command with wildcard Termiantion Name

            
      
            Your question has a couple of
      wider implications.  My first reaction was to say this was an error,
      because in principle the MGC can always know which context a termination
      is in, through audits if necessary.  Then I checked out our audit
      response syntax and realized that the MGC cannot determine the current
      context of a termination if it doesn't know it already.
            
      
            I think the answer has to be that
      we change the production auditOther to include the context ID.
             
            e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
      ContextID  terminationAudit RBRKT 
            
      
            Then the answer to your original
      question is that it is an error. 
            
      
                    -----Original Message-----
            From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
            Sent:   Sunday, January 23, 2000 11:56 PM
            To:    
      MEGACO@STANDARDS.NORTELNETWORKS.COM
            Subject:        Subtract Command with wildcard
      Termiantion Name 
            
      
                    Hi!
                 Here is a small query regarding the case
      where ContextID is "*" and
            Termination Name is fully-specified. Does this implies
      that MGC intends to
            Subtract the specific termination from
            "whichever" context it
      appears in ? Or it is an error because a termination can
            exist only in one context
      and
            ContextID =
      "*" for a specific termination is an error ?
      
            
      
                    Regards
            MadhuBabu

        

------_=_NextPart_001_01BF683F.F8966F20--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:16:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11569
	for ; Wed, 26 Jan 2000 16:16:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3CC41350@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:13:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9980 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:11:24 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9843C290@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:01:24
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25331; Wed, 26 Jan
          2000 16:03:07 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA23953; Wed, 26 Jan
          2000 16:03:10 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:00:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6840.538A647C"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208827@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:03:07 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Preconditions
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6840.538A647C
Content-Type: text/plain;
        charset="iso-8859-1"

This solves the general problem in a way that has been suggested: make the
resolution
specific to packages, rather than creating a general mechanism in the base
protocol.
I agree with this, but we need to decide that this is acceptable before
getting into
specifics of individual instances.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Tuesday, January 25, 2000 8:51 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Preconditions



For some reason the two E-mails I've sent on this topic have been lost.
Anyway, the topic was dealt with in the thread
"questions regarding hook state in residential gateways", running 19-24 Nov
1999.
I am guilty of not drawing a conclusion from that thread.

I think the particular problem of pre-startup line off-hook has the
potential to baffle subscribers depending on their expectations.  I remember
years ago hearing of a case where dial tone in a particular Latin American
city could take up to 20 minutes to follow off-hook.  Offices had people
whose sole job was to wait for that dial tone and pass the phone over to the
caller when it came.  The moral of this is that if people expect to
eventually hear a tone, they will leave the phone off-hook.

Because this particular case can be addressed by a specific package
(Analogue Line Supervision), I suggest we add appropriate behaviour to that
package, as follows:

(1) This behaviour applies only upon reestablishment of MGC control over the
specific termination concerned or the MG as a whole.

(2) If the MGC requests monitoring for an off-hook event and the line is
already off-hook, the MG shall report occurrence of an off-hook event.

(3) If the MGC requests monitoring for an on-hook event and the line is
already on-hook, the MG shall report occurrence of an on-hook.

        -----Original Message-----
From:   Blatherwick, Peter [CAR:AT14:EXCH]
Sent:   Monday, January 24, 2000 11:05 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Preconditions

        My 0.02...

        First, we must avoid application dependencies in the protocol
itself.  Therefore setting pre-conditions as part of the base protocol,
especially if they are aimed at particular events or signals, is not a good
idea IMHO.  I think anything along these lines should be solved in package
definitions since they are at least concerned with application level
information exchange.  I don't think anyone is asking for anything other
than careful package definition, but thought I should say this anyway.

        However, I do see the "invisible state transition problem" as
potentially serious in at least some cases.  I think the best way to solve
this in general is to define, in the affected packages, the detection event
as "detects transition to or already in the requested state".  This would
detect the edge OR if the state already exists.  (I'm pretty sure this is
old ground, but darned if I can find the old thread right now.)

        -- Peter

                -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:   23 Jan, 2000 18:57
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Preconditions

                Let's be careful.  I believe all of these items are defined
in packages.  I don't think there is anything like this in
the base package.  In general, we have talked about defining
events such as hook state as "edge detect", rather than state
detect.  Would it solve the problem to make such events, in
the packages, explicitly defined as change-of-state detected.
Something like "detects the transition...".

                Brian

                > -----Original Message-----
> From: Michael Thomas [ < mailto:mat@cisco.com  >]
> Sent: Saturday, January 22, 2000 3:22 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Preconditions
>
>
>
>
>
> Rosen, Brian writes:
>  > Frankly, I don't think it matters a whole heck of a lot
> what happens in
>  > cases
>  > like this, unless there is some possibility that the MG
> and the MGC will not
>  > sync quickly.
>
>    That's a very big "unless".
>
>  > They do in this case -- the user hangs up, and then the state
>  > is consistent, the next time he goes off hook, the right
> thing happens.  If
>  > anyone
>  > can define a case that doesn't converge like this, please
> speak now,
>
>    A device control protocol like MEGACO is utterly
>    at the mercy of a shared view of the device's
>    state. If the MG and MGC are out of sync and the
>    MG has no way to convey that within the protocol,
>    the protocol is broken. Period. Relagating such things
>    to audits is even more broken, because MGC's in the
>    real world have about zero incentive to do what
>    amounts to device state polling -- which does
>    not scale for high fanout devices like residential gateways.
>
>  > I recommend we say "thanks for sharing"
>
>    This is a base functionality of MGCP -- the
>    only protocol which has any track record
>    thus far. Is this more Anything But MGCP
>    hubris again?
>
>    I would say that the onus is on the naysayers
>    to actually prove there does not exist any
>    unrecoverable and non self-healing state
>    mismatches. It is completely unreasonable for
>    those who would like to have a more robust
>    protocol to prove a negative.
>
>               Mike
>


------_=_NextPart_001_01BF6840.538A647C
Content-Type: text/html;
        charset="iso-8859-1"




RE: Preconditions




        This
solves the general problem in a way that has been suggested: make the
resolution
        

        specific to packages, rather than creating a general
mechanism in the base protocol.
        

        I
agree with this, but we need to decide that this is acceptable before getting
into
        

        specifics of individual instances.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Tuesday, January 25, 2000
  8:51 AM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Preconditions

        
  
        For some reason the two E-mails I've
  sent on this topic have been lost.  Anyway, the topic was dealt with in
  the thread 
        "questions
  regarding hook state in residential gateways", running 19-24 Nov 1999.
  
        I am guilty of not drawing a
  conclusion from that thread. 
        
  
        I think the particular problem of
  pre-startup line off-hook has the potential to baffle subscribers depending on
  their expectations.  I remember years ago hearing of a case where dial
  tone in a particular Latin American city could take up to 20 minutes to follow
  off-hook.  Offices had people whose sole job was to wait for that dial
  tone and pass the phone over to the caller when it came.  The moral of
  this is that if people expect to eventually hear a tone, they will leave the
  phone off-hook.
        
  
        Because this particular case can be
  addressed by a specific package (Analogue Line Supervision), I suggest we add
  appropriate behaviour to that package, as follows:
        
  
        (1) This behaviour applies only upon
  reestablishment of MGC control over the specific termination concerned or the
  MG as a whole.
        
  
        (2) If the MGC requests monitoring
  for an off-hook event and the line is already off-hook, the MG shall report
  occurrence of an off-hook event.
        
  
        (3) If the MGC requests monitoring
  for an on-hook event and the line is already on-hook, the MG shall report
  occurrence of an on-hook.
        
  
          
    
          -----Original Message----- 
          From:   Blatherwick, Peter [CAR:AT14:EXCH] 
          Sent:   Monday, January
    24, 2000 11:05 AM 
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
          Subject:        Re: Preconditions 
          
    
          My 0.02...
    
          
    
          First, we must avoid application
    dependencies in the protocol itself.  Therefore setting pre-conditions
    as part of the base protocol, especially if they are aimed at particular
    events or signals, is not a good idea IMHO.  I think anything along
    these lines should be solved in package definitions since they are at least
    concerned with application level information exchange.  I don't think
    anyone is asking for anything other than careful package definition, but
    thought I should say this anyway.  
          
    
          However, I do see the "invisible
    state transition problem" as potentially serious in at least some
    cases.  I think the best way to solve this in general is to define, in
    the affected packages, the detection event as "detects transition to or
    already in the requested state".  This would detect the edge OR if the
    state already exists.  (I'm pretty sure this is old ground, but darned
    if I can find the old thread right now.)  
          
    
          -- Peter
    
          
    
                  -----Original Message-----
          From:   Rosen, Brian [SMTP:brosen@FORE.COM]
          Sent:   23 Jan, 2000 18:57
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
          Subject:        Re: Preconditions 
          
    
                  Let's
    be careful.  I believe all of these items are defined
          in packages.  I don't
    think there is anything like this in
          the base package.  In general, we have talked about
    defining
          events
    such as hook state as "edge detect", rather than state
          detect.  Would it solve
    the problem to make such events, in
          the packages, explicitly defined as change-of-state
    detected.
          Something like "detects the transition...".
    
          
    
                  Brian 
          
    
                  >
    -----Original Message-----
          > From: Michael Thomas [ <mailto:mat@cisco.com>]
          > Sent: Saturday, January 22, 2000 3:22 PM
          > To: Rosen,
    Brian
          > Cc:
    MEGACO@STANDARDS.NORTELNETWORKS.COM
          > Subject: Preconditions
          >
          >
          >
          >
          >
          > Rosen, Brian
    writes:
          > 
    > Frankly, I don't think it matters a whole heck of a lot
          > what happens
    in
          >  >
    cases
          > 
    > like this, unless there is some possibility that the MG
          > and the MGC will
    not
          > 
    > sync quickly.
          >
          >    That's a very big "unless".
          >
          >  > They do in
    this case -- the user hangs up, and then the state
          >  > is consistent,
    the next time he goes off hook, the right
          > thing happens. 
    If
          >  >
    anyone
          > 
    > can define a case that doesn't converge like this, please
          > speak now,
          >
          >    A
    device control protocol like MEGACO is utterly
          >    at the
    mercy of a shared view of the device's
          >    state.
    If the MG and MGC are out of sync and the
          >    MG has
    no way to convey that within the protocol,
          >    the
    protocol is broken. Period. Relagating such things
          >    to
    audits is even more broken, because MGC's in the
          >    real
    world have about zero incentive to do what
          >    amounts
    to device state polling -- which does
          >    not
    scale for high fanout devices like residential gateways.
          >
          >  > I recommend we
    say "thanks for sharing"
          >
          >    This is a base functionality of MGCP --
    the
          >    only protocol which has any track
    record
          >    thus far. Is this more Anything But
    MGCP
          >    hubris again?
          >
          >    I would
    say that the onus is on the naysayers
          >    to
    actually prove there does not exist any
          >   
    unrecoverable and non self-healing state
          >   
    mismatches. It is completely unreasonable for
          >    those
    who would like to have a more robust
          >    protocol to prove a
    negative.
          >
          >              
    Mike
          > 
        

------_=_NextPart_001_01BF6840.538A647C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:18:05 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11598
	for ; Wed, 26 Jan 2000 16:18:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.85FF0610@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:15:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9983 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:15:03 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1AAB1760@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:05:03
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25706; Wed, 26 Jan
          2000 16:06:46 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA24781; Wed, 26 Jan
          2000 16:06:48 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:03:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208828@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:06:46 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Generally determined by the "kind" of termination requested.
Which is in turn, easily discernable from the Media command.

However, upon reflection, I think it's not a good answer.
I'd propose that we not allow selection of a physical termination,
in which case choose is always create an ephemeral.  In particular,
the following is perfectly legal:
Context=${Add=${}}
What do you get?

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 9:01 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Choosing of ephemeral / physical Termination.
>
>
> Annex B.1 says that "The CHOOSE TerminationID $ may be used
> to signal to the MG
> that it has to create an
> ephemeral Termination or select an idle physical Termination".
> How can MG determine when to create an ephemeral termination
> and when to choose
> idle physical termination.??
> What is the logic behind this decision making?
>
> regards
> -Sachin Mittal
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:20:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11618
	for ; Wed, 26 Jan 2000 16:20:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F253DF70@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:18:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9990 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:17:17 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6A63B8C0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:07:16
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25902; Wed, 26 Jan
          2000 16:08:56 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA25243; Wed, 26 Jan
          2000 16:08:55 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:05:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20882A@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:08:52 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Just sent a couple of messages that address this:
Choose in a ContextId is create a new one

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 9:38 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Subtract Command with wildcard Termination Name
>
>
>
>
> OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
> that choose
>  the context  in which the given Termination exist and
> subtract the termination.
>
>
>
>
> "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>
> Please respond to "Rosen, Brian" 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Subtract Command with wildcard Termination Name
>
>
>
>
> I think this is headed in the wrong direction.  Subtract of wildcarded
> contextId was explicitly allowed for,
> among other things, the response to a ServiceChange with mass
> out of service
> operations pending.
> The MGC must subtract all calls, and do it in a hurry.
>
> It is also useful in a wildcard Audit, with or without W-.
>
> So I think it is allowed, period.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, January 24, 2000 10:06 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Subtract Command with wildcard Termiantion Name
>
>
>
> Your question has a couple of wider implications.  My first
> reaction was to
> say this was an error, because in principle the MGC can
> always know which
> context a termination is in, through audits if necessary.
> Then I checked
> out our audit response syntax and realized that the MGC
> cannot determine the
> current context of a termination if it doesn't know it already.
>
> I think the answer has to be that we change the production
> auditOther to
> include the context ID.
>
> e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
> terminationAudit RBRKT
>
> Then the answer to your original question is that it is an error.
>
>         -----Original Message-----
> From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent:   Sunday, January 23, 2000 11:56 PM
> To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:        Subtract Command with wildcard Termiantion Name
>
>         Hi!
>      Here is a small query regarding the case where ContextID
> is "*" and
> Termination Name is fully-specified. Does this implies that
> MGC intends to
> Subtract the specific termination from
> "whichever" context it appears in ? Or it is an error because
> a termination
> can
> exist only in one context and
> ContextID = "*" for a specific termination is an error ?
>
>         Regards
> MadhuBabu
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:22:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11647
	for ; Wed, 26 Jan 2000 16:22:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3AC40820@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:20:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10002 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:19:59 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.CB335A20@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:09:59
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA26762; Wed, 26 Jan
          2000 16:11:42 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA25945; Wed, 26 Jan
          2000 16:11:45 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:08:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6841.86DE23B2"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20882B@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:11:43 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6841.86DE23B2
Content-Type: text/plain;
        charset="iso-8859-1"


Is the following what you want to do?

Transaction=1000{Context=*{AuditValue=T123}}
Reply = 1000{Context=2222{AuditValue=Context{T123}}

Should be

Transaction=1000{Context=*{AuditValue=T123{Audit{}}}

Reply=1000{Context=2222{AuditValue=T123()

or


Transaction=1000{Context=*{AuditValue=*}}
Reply = 1000{Context=2222{AuditValue=Context{T123},
                         Context=3333{AuditValue=Context{T222,T333},
                         Context=.....}

Should look similar to above

If yes, this is already taken into account by the current ABNF.


Chuong


Tom-PT Taylor wrote:




OK, this is the second comment I've had to this effect -- the other was
received privately.  The one question is whether we want a way to find out
what context a termination is in without subtracting it to find out, in
which case the audit response syntax I suggested might be considered.
Silence means we don't need this additional functiuonality.


        -----Original Message-----
From:  Rosen, Brian [SMTP:brosen@fore.com]
Sent:  Monday, January 24, 2000 10:10 PM
To:    Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:       RE: Subtract Command with wildcard Termination Name

        I think this is headed in the wrong direction.  Subtract of
wildcarded contextId was explicitly allowed for,
among other things, the response to a ServiceChange with mass out of service
operations pending.
The MGC must subtract all calls, and do it in a hurry.


        It is also useful in a wildcard Audit, with or without W-.


        So I think it is allowed, period.


        Brian


        -----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Monday, January 24, 2000 10:06 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Subtract Command with wildcard Termiantion Name


        Your question has a couple of wider implications.  My first reaction
was to say this was an error, because in principle the MGC can always know
which context a termination is in, through audits if necessary.  Then I
checked out our audit response syntax and realized that the MGC cannot
determine the current context of a termination if it doesn't know it
already.


        I think the answer has to be that we change the production
auditOther to include the context ID.


        e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
terminationAudit RBRKT


        Then the answer to your original question is that it is an error.


                -----Original Message-----
From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
Sent:   Sunday, January 23, 2000 11:56 PM
To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:       Subtract Command with wildcard Termiantion Name


                Hi!
     Here is a small query regarding the case where ContextID is "*" and
Termination Name is fully-specified. Does this implies that MGC intends to
Subtract the specific termination from
"whichever" context it appears in ? Or it is an error because a termination
can
exist only in one context and
ContextID = "*" for a specific termination is an error ?


                Regards
MadhuBabu

--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****



------_=_NextPart_001_01BF6841.86DE23B2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









  
        Is the following what you want to do?=20
  
        Transaction=3D1000{Context=3D*{AuditValue=3DT123}} 
        Reply =3D=20
  1000{Context=3D2222{AuditValue=3DContext{T123}}  
        
  
        Should=20
  be 
        
  
        Transaction=3D1000{Context=3D*{AuditValue=3DT=
123{Audit{}}}
        
  
        Reply=3D1000{Context=3D2222{AuditValue=3DT123=
() 
        
  
        or=20
  
        Transaction=3D1000{Context=3D*{AuditValue=3D*}} 
        Reply =3D=20
  1000{Context=3D2222{AuditValue=3DContext{T123},=20
  =

                   &n=
bsp;           &n=
bsp;=20
  Context=3D3333{AuditValue=3DContext{T222,T333},=20
  =

                   &n=
bsp;           &n=
bsp;=20
  Context=3D.....}  
        
  
        Should=20
  look similar to above 
        
  
        If yes, this is already taken into account by the current ABNF.=20
  
        Chuong=20
  
        Tom-PT Taylor wrote:=20
  
         =20
    
        OK, =
this is the second=20
    comment I've had to this effect -- the other was received =
privately. =20
    The one question is whether we want a way to find out what context =
a=20
    termination is in without subtracting it to find out, in which case =
the=20
    audit response syntax I suggested might be considered.  =
Silence means=20
    we don't need this additional functiuonality.=20
    
          -----Original=20
      Message----- 
          From:  Rosen, Brian=20
      [SMTP:brosen@fore.com] 
          Sent:  Monday, January 24, 2000 10:10 =
PM=20
      
          To:    =
Taylor,=20
      Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com=20
      
          Subject:       RE: =
Subtract=20
      Command with wildcard Termination Name=20
      
          I =
think this is=20
      headed in the wrong direction.  Subtract of wildcarded =
contextId was=20
      explicitly allowed for, 
          among other things, the response =
to a=20
      ServiceChange with mass out of service operations=20
      pending. 
          The MGC must subtract all calls, =
and do it in=20
      a hurry.=20
      
          It is =
also useful in=20
      a wildcard Audit, with or without W-.=20
      
          So I =
think it is=20
      allowed, period.=20
      
          Brian=20
      
            -----Original=20
        Message----- 
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]=20
        
            Sent: Monday, =
January 24,=20
        2000 10:06 AM 
            To: =
MEGACO@standards.nortelnetworks.com=20
        
            Subject: Re: =
Subtract Command=20
        with wildcard Termiantion Name 
             =20
        
            Your question has=20
        a couple of wider implications.  My first reaction was to =
say this=20
        was an error, because in principle the MGC can always know =
which context=20
        a termination is in, through audits if necessary.  Then I =
checked=20
        out our audit response syntax and realized that the MGC cannot =
determine=20
        the current context of a termination if it doesn't know it=20
        already.=20
        
            I =
think the answer=20
        has to be that we change the production auditOther to include =
the=20
        context ID.=20
        
            e.g.auditOther =3D=20
        EQUAL TerminationID LBRKT  =
CtxToken EQUAL=20
        ContextID  terminationAudit RBRKT=20
        
            Then the answer to=20
        your original question is that it is an =
error.=20
        
                    -----Original Message----- 
            From:   =
Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]=20
        
            Sent:   Sunday, January 23, 2000 11:56 PM =

            To:   =20
        MEGACO@STANDARDS.NORTELNETWORKS.COM 
            Subject:      =20
        Subtract Command with wildcard Termiantion =
Name=20
        
                    Hi! 
                 Here is a small query =
regarding the=20
        case where ContextID is "*" and 
            Termination Name is fully-specified. Does this =
implies that MGC=20
        intends to 
            Subtract the=20
        specific termination from 
            "whichever" context it appears in ? Or it is an error =
because a=20
        termination can 
            exist=20
        only in one context and 
            ContextID =3D "*" for a specific termination is an =
error=20
        ?=20
        
                    Regards 
            MadhuBabu
        -- =
;
  Alcatel USA, =
Inc           &nb=
sp; Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas =
75075           =
Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc =
****
         =20


------_=_NextPart_001_01BF6841.86DE23B2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:23:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11528
	for ; Wed, 26 Jan 2000 16:12:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F4565BA0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:11:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9979 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:10:01 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.66D46CF0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:00:01
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA25199; Wed, 26 Jan
          2000 16:01:41 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA23635; Wed, 26 Jan
          2000 16:01:44 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 15:58:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208826@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:01:40 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Error code to indicate Termination Out-of-service.
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It was not quite intended for that reason.  We may wish to
add one if the opportunity presents itself.

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 8:41 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Error code to indicate Termination Out-of-service.
>
>
> HI
>      In Section 7.3 There is no error code indicating that
> the specified
> Termination
> is out of service. Does the error code 503 "Service
>  Unavailable"
> intended for
>  this purpose.
>
> regards
> Sachin Mittal.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:24:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11681
	for ; Wed, 26 Jan 2000 16:24:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.82AC3C20@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:22:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10009 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:20:43 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E5AFE670@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:10:43
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA26803; Wed, 26 Jan
          2000 16:12:27 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA26089; Wed, 26 Jan
          2000 16:12:29 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:09:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20882C@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:12:26 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: DTMF and Signals descriptor
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Woops, this should be fixed.  We've just frozen a version, so
it will have to go on a list for the next one.

Brian

> -----Original Message-----
> From: Jo Friedman [mailto:jo@aztek-eng.com]
> Sent: Tuesday, January 25, 2000 10:58 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: DTMF and Signals descriptor
>
>
> Brian,
> You made two statements below that aren't explicitly stated
> in the spec and
> probably would have helped me understand signals better.
>
> "Since the default SignalType for dtmf digits is BRief, the
> duration is
> fixed (or provisioned) it could be overriden by using the
> duration parameter"
>
> "A normal signal has a default duration ...."
>
> Since signalType and duration are optional  should the
> default signalType and
> duration  values be specified in the package? This is
> actually stated in 12.1.4,
> but the packages in Annex E (e.g., basic DTMF generator)
> don't define these
> default values. I think this is where I got confused.
>
> Jo
>
> "Rosen, Brian" wrote:
>
> > See comments below
> >
> > > -----Original Message-----
> > > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > > Sent: Monday, January 24, 2000 5:42 PM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: DTMF and Signals descriptor
> > >
> > >
> > > Please tell me if I'm correct in assuming that there are at least
> > > two ways for the MGC to request the MG to signal DTMF digits on a
> > > physical termination. I also have some V13 comments related to
> > > the signal descriptor below.
> > >
> > > Are both of these correct for dialing '125'?
> > >
> > > Signals {
> > >    dg/pt {
> > >       ind=100,         ; interdigit duration
> > >       tl=[d1,d2,d5]   ; dtmf digits 125
> > >    }
> > > }
> > > In this case how is the signal duration specified?
> > Since the default SignalType for dtmf digits is BRief, the
> duration is
> > fixed (or provisioned) it could be overriden by using the
> duration parameter
> >
> > to specify something else.  SignalType and Duration are
> available for every
> > signal.
> >
> > >
> > > or
> > >
> > > SignalList = 10 {
> > >    SignalType=Timeout,
> > >    Duration=250,
> > >    dg/d1,
> > >    dg/d2,
> > >    dg/d5
> > > }
> > Yes
> >
> > > V13 comments:
> > > In 7.1.11 the last sentence of the 1st paragraph refers to
> > > "sequential play lists". I assume that is the same as "sequential
> > > signal lists" so it should be replaced to avoid confusion.
> > Yes, we should fix this
> >
> > >
> > > In the ABNF for signalListParm the preceding comments contains
> > > the phrase "at most once duration and every signal parameter". I
> > > understand "at most once duration" but I don't understand what is
> > > meant to be conveyed by the rest of the phrase.
> > I think it means that a parameter to a signal can only
> occur once per
> > signal instance in the list (but signal can occur more than
> once, and
> > in each case signal parameters can be included (once).
> >
> > >
> > > In the ABNF for signalListParm if SigSignalType=Timeout is
> > > sigDuration required? The description of timeout in 7.1.11
> > > implies if there is no duration the signal is played until it is
> > > turned off. In a signal list this doesn't make sense because the
> > > first signal in the list would be the only signal played,
> > > wouldn't it?
> > I don't think we talked about this.  A normal signal has a
> default duration
> > and if not specified, that is what you use.  A signal list
> does not have
> > a default duration.  At the moment, I'd say it's an error to specify
> > SignalType = TimeOut and not specify Duration.
> >
> > >
> > > Thanks for any clarifications!
> > > Jo
> > >
> >
> > Brian
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:26:57 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11706
	for ; Wed, 26 Jan 2000 16:26:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CAF8B030@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:24:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10030 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:22:54 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.335E8700@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:12:54
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA27058; Wed, 26 Jan
          2000 16:14:37 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA26659; Wed, 26 Jan
          2000 16:14:39 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:11:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20882D@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:14:35 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: O- and W- in ABNF
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A version and an I-D will be posted tomorrow.  It has some text.

Please note, because the text has to cover both the text encoding
and the binary encoding, the text does not mention the O- or W-
syntax.  It talks about optional commands and wildcarded responses.

Brian

> -----Original Message-----
> From: Jo Friedman [mailto:jo@aztek-eng.com]
> Sent: Tuesday, January 25, 2000 11:59 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: O- and W- in ABNF
>
>
> It seems that "O-" used in commandRequestList and "W-" used in
> subtractRequest and auditRequest are not described anywhere.
>
> An archived message from Nancy stated that: "Megaco/H.248 does
> have a way to mark a command as optional (O-)" and this
> corresponds to the discussion of optional in section 8.
>
> I'm guessing that W- corresponds to this statement found in 7.2.5
> and 7.2.6:
> "If the TerminationId is wildcarded, only one command return is
> generated, with the contents containing the union of the values
> of all Terminations matching the wildcard." (Note this statement
> is missing from the Subtract command in 7.2.3). Did I guess
> correctly?
>
> These notations should be better documented in the spec,
> especially for those of us who don't know the secret handshake.
>
> Thanks,
> Jo
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:35:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11871
	for ; Wed, 26 Jan 2000 16:35:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0E80F000@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:33:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10107 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:32:09 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7E38B560@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:22:09
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA28062; Wed, 26 Jan
          2000 16:23:48 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA28946; Wed, 26 Jan
          2000 16:23:51 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Wed, 26 Jan 2000 16:20:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20882F@whq-msgusr-02.fore.com>
Date:         Wed, 26 Jan 2000 16:23:49 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Root Package
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Re: Globals

Globals behave like global variables in a program.  If they are
changed by one piece of code, the change is visible in other
pieces.  If two parts change it "simultaneously", the result is
"unpredictable".  It's of course completely predictable, but
the writer of the code won't know.  So, the usual dictum applies
-don't change global variables unless you know what you are doing.

The problem has existed since the invention of subroutines, and
continues to this day.  Don't expect any miracles.

The next version states Global is declared in "Characteristics"

I think, pending review of the above mentioned text, that we
declare this closed.

The other item (do processing times include network delay), I agree
is still open.  We have waffled a bit on this, and I'm as guilty as
the next.  Either times include an estimate of network delay or they
don't.  Note that both ends MUST have an idea of network delay, or
timers don't work.  So, I suspect whether the values include it
or not is a don't care, and we should just decide and make the text
consistent.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:chsharp@cisco.com]
> Sent: Tuesday, January 25, 2000 5:17 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Root Package
>
>
> Section:        6.2.3
> Category:       Open Issue
> Issue:          The draft text does not address packages
> adding properties to root.
> This issue was identified by the IETF editor but has not yet
> been resolved
> (issue 3). The issue is, that some packages need a property
> which is the
> same for all terminations that implement the package.
> Quantify of is an
> example, or bandwidth perhaps.
> Discussion:             A continuation of the discussion that
> has occurred on the
> Megaco mailing list so far is needed in order to resolve the issue.
>
> v13 Status:             Partially CLOSED ? Section 6.2.4
> states that "A property may
> be declared as "Global" which has a single value shared by
> all terminations
> realizing the package". Not clear how this value is
> synchronized between
> terminations as there are no rules for how and when updates
> can be made
> (e.g. by multiple terminations simultaneously ?).  There are
> no procedures
> in Section 12 on how to declare a value as Global.
> Suggested Text is welcome.
>
>
> Section:        8.2.3, third paragraph
> Category:       Technical
> Issue:          The draft text specifies that "A property of root
> (normalMGExecutionTime) is settable...Another property
> (normalMGCExecutionTime) is settable...". Neither of these
> properties are
> defined anywhere else and their definition as stated here are
> slightly
> inaccurate as they ignore network transit time.
> Proposal:       It is recommended that a Base Root Package
> with these properties
> are defined. Furthermore, it is recommended to clarify the
> description of
> these two properties to reflect the fact that they only account for
> processing time in a node and do not include any network
> delays, thus they
> do specify an absolute value for when a response might be expected.
>
> v13 Status:     SEMI-CLOSED. A base root package with the two
> properties has
> been defined.  Suggest adding the following text to the
> description of each
> timer:  "This timer must take into account processing delay
> in the (MGC or
> MG) in addition to network transit delay."
>
>
> Section:        D.1.4, second paragraph
> Category:       Technical
> Issue:          The draft text specifies that "The root
> termination has a property
> (ProvisionalResponseTimerValue), which can be set to the requested...".
> However, this property is not defined anywhere else in the document.
> Proposal:       It is recommended that a Base Root Package
> with this property is
> defined.
>
> v13 Status:     CLOSED.  Added to root package E.2.1.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 16:53:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12222
	for ; Wed, 26 Jan 2000 16:53:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93A18680@standards.nortelnetworks.com>; Wed, 26 Jan 2000 16:51:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10171 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 16:49:34 -0500
Received: from fw3.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.E991B7B0@standards.nortelnetworks.com>;
          Wed, 26 Jan 2000 16:39:28 -0500
Received: (from uucp@localhost) by fw3.dsccc.com (8.8.8+Sun/8.8.8) id PAA07917
          for ; Wed, 26 Jan 2000 15:40:40
          -0600 (CST)
Received: from relay2.dsccc.com(10.17.102.19) by fw3 via smap (V2.0) id
          xmaa07809; Wed, 26 Jan 00 15:40:00 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id PAA22466 for
          ; Wed, 26 Jan 2000 15:40:59
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA7324 for
          ; Wed, 26 Jan 2000 15:39:54 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id PAA20983 for ; Wed, 26
          Jan 2000 15:39:08 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id PAA09714
          for ; Wed, 26 Jan 2000 15:39:08
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF20882B@whq-msgusr-02.fore.com>
Content-Type: multipart/alternative;
              boundary="------------14382C36C45E5B404CA1A74D"
Message-ID:  <388F697B.74F874A1@usa.alcatel.com>
Date:         Wed, 26 Jan 2000 15:39:08 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Subtract Command with wildcard Termination Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------14382C36C45E5B404CA1A74D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The ABNF is

auditReply = (AuditValueToken / AuditCapToken) {contextAudit /
auditOther)

My example reply with contextAudit and your example reply with
auditOther.

The reason I used contextAudit because I am trying to follow 7.2.5 which
try to show how to audit
a context.
Look like both ways are correct.  How can we tell which one to use or
when to use
contextAudit vs auditOther?

Chuong

"Rosen, Brian" wrote:

>
>
>      Is the following what you want to do?
>
>      Transaction=1000{Context=*{AuditValue=T123}}
>      Reply = 1000{Context=2222{AuditValue=Context{T123}}
>
>      Should be
>
>      Transaction=1000{Context=*{AuditValue=T123{Audit{}}}
>
>      Reply=1000{Context=2222{AuditValue=T123()
>
>      or
>
>      Transaction=1000{Context=*{AuditValue=*}}
>      Reply = 1000{Context=2222{AuditValue=Context{T123},
>
>      Context=3333{AuditValue=Context{T222,T333},
>                               Context=.....}
>
>      Should look similar to above
>
>      If yes, this is already taken into account by the current
>      ABNF.
>
>      Chuong
>
>      Tom-PT Taylor wrote:
>
>     >
>     >
>     > OK, this is the second comment I've had to this effect --
>     > the other was received privately.  The one question is
>     > whether we want a way to find out what context a
>     > termination is in without subtracting it to find out, in
>     > which case the audit response syntax I suggested might be
>     > considered.  Silence means we don't need this additional
>     > functiuonality.
>     >
>     >      -----Original Message-----
>     >      From:  Rosen, Brian [SMTP:brosen@fore.com]
>     >      Sent:  Monday, January 24, 2000 10:10 PM
>     >      To:    Taylor, Tom-PT [CAR:B904:EXCH];
>     >      MEGACO@standards.nortelnetworks.com
>     >      Subject:      RE: Subtract Command with wildcard
>     >      Termination Name
>     >
>     >      I think this is headed in the wrong direction.
>     >      Subtract of wildcarded contextId was explicitly
>     >      allowed for,
>     >      among other things, the response to a ServiceChange
>     >      with mass out of service operations pending.
>     >      The MGC must subtract all calls, and do it in a
>     >      hurry.
>     >
>     >      It is also useful in a wildcard Audit, with or
>     >      without W-.
>     >
>     >      So I think it is allowed, period.
>     >
>     >      Brian
>     >           -----Original Message-----
>     >           From: Tom-PT Taylor
>     >           [mailto:taylor@nortelnetworks.com]
>     >           Sent: Monday, January 24, 2000 10:06 AM
>     >           To: MEGACO@standards.nortelnetworks.com
>     >           Subject: Re: Subtract Command with wildcard
>     >           Termiantion Name
>     >
>     >
>     >           Your question has a couple of wider
>     >           implications.  My first reaction was to say this
>     >           was an error, because in principle the MGC can
>     >           always know which context a termination is in,
>     >           through audits if necessary.  Then I checked out
>     >           our audit response syntax and realized that the
>     >           MGC cannot determine the current context of a
>     >           termination if it doesn't know it already.
>     >
>     >           I think the answer has to be that we change the
>     >           production auditOther to include the context ID.
>     >
>     >           e.g.auditOther = EQUAL TerminationID LBRKT
>     >           CtxToken EQUAL ContextID  terminationAudit RBRKT
>     >
>     >           Then the answer to your original question is
>     >           that it is an error.
>     >
>     >                   -----Original Message-----
>     >           From:   Sachin Mittal
>     >           [SMTP:samittal@HSS.HNS.COM]
>     >           Sent:   Sunday, January 23, 2000 11:56 PM
>     >           To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>     >           Subject:      Subtract Command with wildcard
>     >           Termiantion Name
>     >
>     >                   Hi!
>     >                Here is a small query regarding the case
>     >           where ContextID is "*" and
>     >           Termination Name is fully-specified. Does this
>     >           implies that MGC intends to
>     >           Subtract the specific termination from
>     >           "whichever" context it appears in ? Or it is an
>     >           error because a termination can
>     >           exist only in one context and
>     >           ContextID = "*" for a specific termination is an
>     >           error ?
>     >
>     >                   Regards
>     >           MadhuBabu
>     >
>      --
>        Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>        1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>        **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------14382C36C45E5B404CA1A74D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



The ABNF is

        auditReply = (AuditValueToken / AuditCapToken) {contextAudit / auditOther)

        My example reply with contextAudit and your example reply with auditOther.

        The reason I used contextAudit because I am trying to follow
7.2.5 which try to show how to audit

        a context.

        Look like both ways are correct.  How can we tell which one to
use or when to use

        contextAudit vs auditOther?

        Chuong

        "Rosen, Brian" wrote:

         

        Is
the following what you want to do?

        Transaction=1000{Context=*{AuditValue=T123}}

        Reply = 1000{Context=2222{AuditValue=Context{T123}} 

        Should
be 

        Transaction=1000{Context=*{AuditValue=T123{Audit{}}}

        Reply=1000{Context=2222{AuditValue=T123() 

        or

        Transaction=1000{Context=*{AuditValue=*}}

        Reply = 1000{Context=2222{AuditValue=Context{T123},

                                
Context=3333{AuditValue=Context{T222,T333},

                                
Context=.....} 

        Should
look similar to above 

        If yes, this is already taken into account by the current ABNF.

        Chuong

        Tom-PT Taylor wrote:

         

        OK, this is the
second comment I've had to this effect -- the other was received privately. 
The one question is whether we want a way to find out what context a termination
is in without subtracting it to find out, in which case the audit response
syntax I suggested might be considered.  Silence means we don't need
this additional functiuonality.

          -----Original Message-----

          From:  Rosen, Brian [SMTP:brosen@fore.com]

          Sent:  Monday, January
24, 2000 10:10 PM

          To:    Taylor,
Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com

          Subject:     

RE: Subtract Command with wildcard Termination Name

          I think this
is headed in the wrong direction.  Subtract of wildcarded contextId
was explicitly allowed for,

          among other
things, the response to a ServiceChange with mass out of service operations
pending.

          The MGC must
subtract all calls, and do it in a hurry.

          It is also useful
in a wildcard Audit, with or without W-.

          So I think it
is allowed, period.

          Brian

            -----Original Message-----

            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]

            Sent: Monday, January 24,
2000 10:06 AM

            To: MEGACO@standards.nortelnetworks.com

            Subject: Re: Subtract Command
with wildcard Termiantion Name

             

            Your question
has a couple of wider implications.  My first reaction was to say
this was an error, because in principle the MGC can always know which context
a termination is in, through audits if necessary.  Then I checked
out our audit response syntax and realized that the MGC cannot determine
the current context of a termination if it doesn't know it already.

            I think the answer
has to be that we change the production auditOther to include the context
ID.

            e.g.auditOther
= EQUAL TerminationID LBRKT 
CtxToken EQUAL ContextID  terminationAudit RBRKT

            Then the answer
to your original question is that it is an error.

                    -----Original
Message-----

            From:   Sachin
Mittal [SMTP:samittal@HSS.HNS.COM]

            Sent:   Sunday,
January 23, 2000 11:56 PM

            To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

            Subject:     

Subtract Command with wildcard Termiantion Name

                    Hi!

                 Here is a
small query regarding the case where ContextID is "*" and

            Termination Name is fully-specified.
Does this implies that MGC intends to

            Subtract the specific termination
from

            "whichever" context it appears in
? Or it is an error because a termination can

            exist only in one context and

            ContextID = "*" for a specific termination
is an error ?

                    Regards

            MadhuBabu
          

        

        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 
        

        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------14382C36C45E5B404CA1A74D--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 21:13:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14632
	for ; Wed, 26 Jan 2000 21:13:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F0F90DC0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 21:11:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10416 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 21:10:08 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B9408700@standards.nortelnetworks.com>; Wed, 26 Jan 2000
          21:10:07 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 26 Jan 2000 20:11:43 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 26
          Jan 2000 21:11:28 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Wed, 26 Jan 2000 21:11:27 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Wed, 26 Jan 2000 21:11:25 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Megaco Extensions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The primary form of extension of the protocol is through packages.  Auditing
of packages is a separate issue.  It is also possible to have extensions on
modem types and MUX types, and as parameters in ServiceChange.
AuditCapability should pick up the modem and MUX type extensions.  There is
no point in auditing ServiceChange extensions, since ServiceChange precedes
any audits.

Conclusion: issued closed except for packages.

                    From:         Chip Sharp 
                    Subject:      Auditing
                    Content-Type: text/plain; charset="us-ascii";
format=flowed

                    Section:        7.1.12, table
                    Category:       Technical
                    Issue:          The draft text lists "Extensions" as
auditable items,
                    however the rest of the draft recommendation does not
define how auditing
                    of extensions is performed.
                    Proposal:       It is recommend, that the example API
and the protocol
                    syntax are extended to include auditing of extensions.

                    v13 Status:     The new draft has removed extensions
from the table.   The
                    implications are there are no extensions to descriptors
allowed in the new
                    draft, only extensions to parameters(?).  Also, there is
no way to audit
                    for extensions.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Jan 26 21:25:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14741
	for ; Wed, 26 Jan 2000 21:25:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9F58AEB0@standards.nortelnetworks.com>; Wed, 26 Jan 2000 21:23:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10443 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 26 Jan 2000 21:22:37 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.780452B0@standards.nortelnetworks.com>; Wed, 26 Jan 2000
          21:22:37 -0500
Received: from zmers013 by smtprch1.nortel.com; Wed, 26 Jan 2000 20:23:42 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Wed, 26
          Jan 2000 21:23:30 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Wed, 26 Jan 2000 21:23:29 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Wed, 26 Jan 2000 21:23:26 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Auditing Of Packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Every termination should support digit map capability, so digit map names
and values are all you would want to audit.  AuditValue is logical for that.
This leaves packages, which happen to be tied into what types of ephemeral
termination an MG will support.  Doctrine coming out of Washington was that
you would find out the latter by digging out the termination naming pattern,
then walking through  the naming tree to determine the capabilities
supported by each branch.  As Chip points out immediately below, however,
you cannot currently determine the packages supported by a termination until
it has been instantiated.  It seems reasonable that AuditCapability also
return a PackageList, the packages potentially supported by the termination
as opposed to those actually invoked.


                    From:         Chip Sharp 
                    Subject:      Auditing

                    Section:        7.2.6, last line
                    Category:       Technical
                    Issue:          The draft text specifies that "DigitMap
and Packages are
                    not legal in AuditCapability". This is inconsistent with
the return
                    parameters shown for the example API. Furthermore, it
would seem reasonable
                    to be able determine what packages a termination (or
gateway) supports as
                    well as whether digit map is supported or not. Although
packages can be
                    audited with AuditValue, it would seem to make more
sense to allow it in
                    AuditCapability.
                    Proposal:       It is proposed to strike the above
sentence and allow for
                    auditing of these two capabilities.

                    v13 Status:     OPEN. No relevant text changed.

                    Section:        7.2.6
                    Category:       Open Issue
                    Issue:          The current draft text does not specify
how to audit
                    ephemerals at startup. This issue was identified by the
IETF editor but has
                    not yet been resolved (issue 1). The issue is, that when
you boot and have
                    not yet created any ephemeral terminations, how do you
know what the MG can
                    do. For example, how do you know if the MG has say an IP
interface, and ATM
                    interface, an MPLS interface or a Frame Relay interface
. If you could
                    audit something, you could look at the "network" value
in LocalControl.
                    Discussion:             A continuation of the discussion
that has occurred
                    on the Megaco mailing list so far is needed in order to
resolve the issue.

                    v13 Status:     OPEN. No relevant text has been added.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 02:57:29 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01247
	for ; Thu, 27 Jan 2000 02:57:28 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E72F67A0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 2:55:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10668 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 02:53:03 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9DCC0550@standards.nortelnetworks.com>; Thu, 27 Jan 2000 2:52:57
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA20302; Thu, 27 Jan
          2000 12:00:17 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.00209338 ; Thu, 27 Jan 2000 11:25:48 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.002092BB.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 11:29:11 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Agreed that "Choose in a ContextId is create a new one".  Does this mean that
in MOVE $ in ContextID is allowed (Move a termination to a "new" context)? Or is
it that
$ in ContextID is only allowed in case of ADD?

We need to add the following line somewhere in the text:
"A $ in ContextID means to CREATE a new context and except ADD (and MOVE ??)
it can't appear in any other command"

Regarding ContextID * and $ in Subtract our thinking was:
1) ContextID * means "search for a termination in all contexts and subtract from
it"
2) ContextId $ means "find the context in which the termination exists and
subtract it from that context"
By this logical meaning it seems that both are valid. But now we agree to what
you say and (2) is not allowed.









"Rosen, Brian"  on 01/27/2000 02:38:52 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Subtract Command with wildcard Termination Name




Just sent a couple of messages that address this:
Choose in a ContextId is create a new one

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 9:38 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Subtract Command with wildcard Termination Name
>
>
>
>
> OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
> that choose
>  the context  in which the given Termination exist and
> subtract the termination.
>
>
>
>
> "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>
> Please respond to "Rosen, Brian" 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Subtract Command with wildcard Termination Name
>
>
>
>
> I think this is headed in the wrong direction.  Subtract of wildcarded
> contextId was explicitly allowed for,
> among other things, the response to a ServiceChange with mass
> out of service
> operations pending.
> The MGC must subtract all calls, and do it in a hurry.
>
> It is also useful in a wildcard Audit, with or without W-.
>
> So I think it is allowed, period.
>
> Brian
>
> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Monday, January 24, 2000 10:06 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Subtract Command with wildcard Termiantion Name
>
>
>
> Your question has a couple of wider implications.  My first
> reaction was to
> say this was an error, because in principle the MGC can
> always know which
> context a termination is in, through audits if necessary.
> Then I checked
> out our audit response syntax and realized that the MGC
> cannot determine the
> current context of a termination if it doesn't know it already.
>
> I think the answer has to be that we change the production
> auditOther to
> include the context ID.
>
> e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL ContextID
> terminationAudit RBRKT
>
> Then the answer to your original question is that it is an error.
>
>         -----Original Message-----
> From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent:   Sunday, January 23, 2000 11:56 PM
> To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:        Subtract Command with wildcard Termiantion Name
>
>         Hi!
>      Here is a small query regarding the case where ContextID
> is "*" and
> Termination Name is fully-specified. Does this implies that
> MGC intends to
> Subtract the specific termination from
> "whichever" context it appears in ? Or it is an error because
> a termination
> can
> exist only in one context and
> ContextID = "*" for a specific termination is an error ?
>
>         Regards
> MadhuBabu
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 03:09:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01382
	for ; Thu, 27 Jan 2000 03:09:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94DEA450@standards.nortelnetworks.com>; Thu, 27 Jan 2000 3:07:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10679 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 03:05:50 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.67D25AB0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 3:05:46
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA20833; Thu, 27 Jan
          2000 12:07:02 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.00213011 ; Thu, 27 Jan 2000 11:32:29 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.00212E23.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 11:35:50 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Its true that the type of termination should not be identified by looking into
the descriptor
information. Somewhere in the text this should be added that " $ if it appears
alone indicates
ephemeral termination and partial $ (ex foo$) indicates selection of a physical
termination
(a circuit within a trunk group)".




"Rosen, Brian"  on 01/27/2000 02:36:46 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.




Generally determined by the "kind" of termination requested.
Which is in turn, easily discernable from the Media command.

However, upon reflection, I think it's not a good answer.
I'd propose that we not allow selection of a physical termination,
in which case choose is always create an ephemeral.  In particular,
the following is perfectly legal:
Context=${Add=${}}
What do you get?

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 9:01 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Choosing of ephemeral / physical Termination.
>
>
> Annex B.1 says that "The CHOOSE TerminationID $ may be used
> to signal to the MG
> that it has to create an
> ephemeral Termination or select an idle physical Termination".
> How can MG determine when to create an ephemeral termination
> and when to choose
> idle physical termination.??
> What is the logic behind this decision making?
>
> regards
> -Sachin Mittal
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 03:58:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01659
	for ; Thu, 27 Jan 2000 03:58:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6DC6D7F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 3:56:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10690 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 03:54:34 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.35486920@standards.nortelnetworks.com>; Thu, 27 Jan 2000 3:54:27
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA05662 for
          ; Thu, 27 Jan 2000 14:54:33
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.00308648 ; Thu, 27 Jan 2000 14:20:01 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.00308569.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 14:23:21 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      ServiceChange in Null context.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

According to Section 7.2.8 it is mentioned that when a termination receives
ServiceChange
command with graceful ServiceChangeMethod and ServiceChangeDelay = NULL then
MG should set state= "test" and INDEFINITELY wait for Subtract command.
what is the behavior of MG when the termination is in NULL context?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 04:11:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01787
	for ; Thu, 27 Jan 2000 04:11:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F585450@standards.nortelnetworks.com>; Thu, 27 Jan 2000 4:09:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10703 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 04:07:50 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.11EF1DA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 4:07:47
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA06917 for
          ; Thu, 27 Jan 2000 15:07:53
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.0031BFC3 ; Thu, 27 Jan 2000 14:33:23 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.0031BEA6.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 14:36:43 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Importance of ContextID in ServiceChange command
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HI all

It should be mentioned somewhere in the text that there is no siginificance of
ContextID in case of ServiceChange Command. The ServiceChange command
is for terminations and no validation is done on ContextID should be done.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 05:47:31 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02239
	for ; Thu, 27 Jan 2000 05:47:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD2C67C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 5:45:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10794 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 05:43:53 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7BFFE780@standards.nortelnetworks.com>; Thu, 27 Jan 2000 5:43:48
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id QAA10296 for
          ; Thu, 27 Jan 2000 16:01:25
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.0036A51E ; Thu, 27 Jan 2000 15:26:52 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.0036A311.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 15:30:12 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Madhu Babu 
Subject:      ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When a termination is marked out-of-service through ServiceChange command
using graceful/ forced ServiceChangeMethod, and MGC has not yet sent Subtract
command for that termination, what is the processing associated at MG when
second
ServiceChange command arrives with Restart method. Should it be removed from
context or disallow second ServiceChange command?

There is no text in Version 13  mentioning that when terminations are brought
back
to service using Restart ServiceChange command, what the context of the
terminations
will be. Version 11 did mention this as "the Termiantions are assumed to now not
be
associated with any Context".


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:17:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04618
	for ; Thu, 27 Jan 2000 08:17:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A98461D0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:15:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10898 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:14:13 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.7F0552C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:14:13
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id
          IAA16259 for ; Thu, 27 Jan 2000
          08:15:55 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.0048DD57 ; Thu, 27 Jan 2000 08:15:52 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.0048DC91.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:17:41 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Lack of Propper Tagging in H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The ASN.1 specification of the protocol contained within Annex A lacks proper
tagging for the defined parameters.  In order to clearly distinguish messages,
parameters, and values included, unique tagging is an essential requirement of
the protocol. Thus, with the existing specification, a receiving entity would
have a difficult time trying to determine whether a received transaction
contained an AddRequest, a ModifyRequest, MoveRequest, etc.

Note that the ABNF as described in Annex B contains tags (or tokens) for the
different parameters.

Section 3.1 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248_asn1-tagging.DOC )
provides a modified ASN.1 including tags.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:25:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04897
	for ; Thu, 27 Jan 2000 08:25:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C83E5440@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:23:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10913 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:21:58 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.943F5310@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:21:58
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id
          IAA16850 for ; Thu, 27 Jan 2000
          08:23:46 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004994D0 ; Thu, 27 Jan 2000 08:23:42 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=VO1fajWx8TnyyYuAaSgcRDmYvT2IiK1EadKpiDmOfkVeLnEH9WqOn6VB"
Content-Disposition: inline
Message-ID:  <85256873.004994AE.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:25:32 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Additional Call Information Needed in H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=VO1fajWx8TnyyYuAaSgcRDmYvT2IiK1EadKpiDmOfkVeLnEH9WqOn6VB
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




There are applications in today
--0__=VO1fajWx8TnyyYuAaSgcRDmYvT2IiK1EadKpiDmOfkVeLnEH9WqOn6VB
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


?s PSTN that require the PSTN switch to provide
an answer indication to the calling analog line when the call is answer=
ed.  Some
applications include payphones with user-premised based billing, small
hotel/motels, universities, etc.  To accommodate these applications whe=
n in a
VoP network where the network access continues to be a traditional anal=
og line,
the MGC needs to be able to indicate to the MG that an answer indicatio=
n needs
to be provided to the calling line.

In addition there is a need to be able to instruct an MG which of sever=
al call
clearing with error treatment options is to be applied by the MGC for a=
n analog
line in certain error cases (e.g., the user does not hang up the phone)=
.

Section 3 of a Telcordia Technologies contribution to SG 16 (which can =
be found
at ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-callinfo.=
DOC )
provides a proposal for providing such an answer indication to the call=
ing line
as well as the specific call release treatment when call clearing with =
error
treatment is to be provided.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com
=

--0__=VO1fajWx8TnyyYuAaSgcRDmYvT2IiK1EadKpiDmOfkVeLnEH9WqOn6VB--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:32:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05074
	for ; Thu, 27 Jan 2000 08:32:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C315DFF0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:30:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10924 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:28:27 -0500
Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.7BBCA580@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:28:26
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id
          IAA21105 for ; Thu, 27 Jan 2000
          08:30:14 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004A2F17 ; Thu, 27 Jan 2000 08:30:17 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=8WdwL47UMsLk8gUG04q8qZ6MF3Hj38J5mpeHhJoK8HvIU9hgkyrHJJ8X"
Content-Disposition: inline
Message-ID:  <85256873.004A2E00.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:32:05 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Essential Tones Missing from H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=8WdwL47UMsLk8gUG04q8qZ6MF3Hj38J5mpeHhJoK8HvIU9hgkyrHJJ8X
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline




The version of H.248 prior to the White Paper included a list of tones that
could be identified by the MGC to the MG.

The White paper (Megaco Version 12 and 13) only lists a minor subset of these
tones.  It is important to allow as many of the currently used tones to be
identified as possible.

Two important tones missing from this list include: recall dial tone and stutter
dial tone.  Recall Dial tone is used in North American networks to provide an
indication that the caller should provide more information (e.g., user has
dialed a service access code, but has not provided a called number).  Stutter
dial tone is used to indicate that messages are waiting for the user for the
Message Service Application.  These tones are widely used in North America and
it is essential that these be included within H.248.

Barge-In Tone, Incoming Additional Call Tone, Priority Additional Call Tone, and
Expensive Route Warning Tone are required for Centrex type applications.  For
these tones a Centrex Tone Package is proposed.

Barge-In Tone indicates to a party on a call that another user has bridged onto
their call (e.g., supervisor observing telemarketer).  Additional Call Tone is
used to inform a user that another call, which is from outside of the user
--0__=8WdwL47UMsLk8gUG04q8qZ6MF3Hj38J5mpeHhJoK8HvIU9hgkyrHJJ8X
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


?s
Centrex, is waiting for the user.  Priority Additional Call Tone is use=
d to
indicate to the user that a priority call (typically) another Centrex u=
ser is
waiting for them.  This last tone is used for example by a boss to inte=
rrupt the
conversation of an employee.  Expensive Route Warning Tone is used when=
 a route
designated as expensive is selected for a call, which affords the calle=
r with
the opportunity to abandon the call.

The specifics for these tones are provided in Section 3 of a Telcordia
Technologies contribution to SG 16 (which can be found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-tones.DOC ).=



-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com
=

--0__=8WdwL47UMsLk8gUG04q8qZ6MF3Hj38J5mpeHhJoK8HvIU9hgkyrHJJ8X--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:45:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05327
	for ; Thu, 27 Jan 2000 08:45:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94E094C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:43:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10943 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:41:46 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.583F7E50@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:41:46
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          IAA20997 for ; Thu, 27 Jan 2000
          08:43:34 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004B6513 ; Thu, 27 Jan 2000 08:43:30 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004B62DE.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:45:15 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Need to support the playing of announcements in
              H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In the PSTN today, certain error conditions warrant the provision of an
announcement to the calling user.  When the error condition occurs in a Voice
over Packet (VoP) network, the VOP network needs to be able to provide the
announcement.  In order to provide the desired announcement, the MGC needs to
signal to the MG or the Announcements Server the announcement to be played.  It
is desirable not to standardize the specific announcements themselves as network
operators will need flexibility depending on local conditions for the
announcement to be provided.  However, what can be standardized is the label
that identifies an announcement is to be played.  An announcement identifier
with a generic announcement description and possibly a field to indicate the
number of cycles the announcements are to be played.

Annex E.12 (Announcement) appears to be missing from the White Paper (MegacoH248
Version 12).  A Telcordia Technologies contribution to SG 16 (which can be found
at ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-announcements.DOC
) provides some proposals to address this issue.  Specifically, Section 3.1 of
this contribution proposes a set of standardized announcements/situations.
Section 3.2 of this contribution proposes a set of announcement identifiers that
could be standardized, while the corresponding announcements are
network-specific.



-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:51:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05388
	for ; Thu, 27 Jan 2000 08:51:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C225310@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:49:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10956 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:48:17 -0500
Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.4105F290@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:48:16
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id
          IAA22928 for ; Thu, 27 Jan 2000
          08:50:00 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004BFAA0 ; Thu, 27 Jan 2000 08:49:53 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=7SuSEXFSFJMKUYUmlmGYbKuzJC59Aer8CdU4fCiN4N77rESUgkvXNJE0"
Content-Disposition: inline
Message-ID:  <85256873.004BF9FA.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:51:43 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Updates to References Section of H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=7SuSEXFSFJMKUYUmlmGYbKuzJC59Aer8CdU4fCiN4N77rESUgkvXNJE0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline






The documents referenced in Annex C of H.248 (e.g., Q.763) should be added as
normative references as they are needed to implement the protocol.

Specifically, the following should be added as normative references since they
are needed to implement the protocol of Annex C:

Q.1901  (informally known as Q.BICC)

Q.763-1999  (ISUP)

Q.2630  (AAL2 Signaling)

Q.2931  (B-ISDN Network Access Layer Signaling)

Q.2941.3  (Generic Identifier Transport
--0__=7SuSEXFSFJMKUYUmlmGYbKuzJC59Aer8CdU4fCiN4N77rESUgkvXNJE0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


? Extensions for BICC)

Q.931-1998 (N-ISDN Network Access Layer Signaling)

In addition, the reference to Q.931 in the Informative References secti=
on should
be removed since it is being added to the Normative references section.=



Section 3.1 of a Telcordia Technologies contribution to SG 16 (which ca=
n be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DO=
C )
provides a proposal for updating the references.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


=

--0__=7SuSEXFSFJMKUYUmlmGYbKuzJC59Aer8CdU4fCiN4N77rESUgkvXNJE0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 08:56:47 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05448
	for ; Thu, 27 Jan 2000 08:56:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1FBFC510@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:54:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10972 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 08:53:29 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.FB3B51F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 8:53:29
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id
          IAA19268 for ; Thu, 27 Jan 2000
          08:55:17 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004C7742 ; Thu, 27 Jan 2000 08:55:12 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004C76D8.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 08:57:02 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Additional Call Information Needed in H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

According to Section 7.1.9, can an embedded EventsDescriptor contain an embedded
SignalsDescriptor?

If it can, then the following is possible:  SignalsDescriptor (embedded Events
Descriptor [embedded SignalsDescriptor]). In addition, then the following should
be added to the next to last paragraph of 7.1.9:

An embedded SignalsDescriptor may contain an embedded EventsDescriptor and vice
versa.  However, only two levels of embedding are permitted.  For example, an
embedded EventsDescriptor contained within an embedded Signals Descriptor shall
not itself contain an embedded SignalsDescriptor.

If this is not allowed, then the following should be added to the next to last
paragraph of 7.1.9:

An embedded SignalsDescriptor shall not contain an embedded EventsDescriptor.


Section 3.2 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
provides proposals for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:06:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05655
	for ; Thu, 27 Jan 2000 09:06:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.86028D70@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:04:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10985 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:02:52 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.4A847330@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:02:51
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          JAA22837 for ; Thu, 27 Jan 2000
          09:04:39 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004D554D ; Thu, 27 Jan 2000 09:04:41 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004D54A2.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:06:31 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Comments on 7.1.13 on DigitMaps in H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Section 7.1.13 on Digit Maps needs to take into account one additional case.
The case where a received digit string matches a complete string in the digit
map, but also matches part of a longer string in the digit map.  This case
requires the use of critical (or short) inter-digit timing to determine whether
any further digits are required.  In this case, the short timer could be used
monitor for additional digits.

Steps 3 and 4 require clarification to address this issue.


It is proposed that items 3 and 4 be replaced with the following:
3.   If the result does not match any entry and is under-qualified (partially
matches at least one entry in the DigitMap), do nothing further.
4.   If the result is a match and is under-qualified (partially matches at least
one other entry in the DigitMap), apply the short timer and await further
digits. If the timer expires and no digits are received or an end-of-dialing
indication is received, send the current dial string to the MGC.  If one or more
digits are received apply steps 1 through 5 again.
5.   If the result is a match and is over-qualified (i.e., no further digits
could possibly produce a match), send the current dial string to the MGC.

Section 3.3 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
provides a proposal for resolving this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:09:04 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05681
	for ; Thu, 27 Jan 2000 09:09:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CDE87780@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:06:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10992 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:05:45 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B216E280@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:05:45
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id
          JAA20780 for ; Thu, 27 Jan 2000
          09:07:33 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004D9984 ; Thu, 27 Jan 2000 09:07:35 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004D98F8.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:09:25 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Comments on Command Error Codes, 7.3 of H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When the MGC requests the MG to add a physical termination to a context, let us
say, an analog line, it is possible that the actual physical interface from the
MG to the customer premises could use one of a number of transport technologies
(e.g., Integrated Digital Loop Carrier [IDLC] as defined in ITU-T Recommendation
G.xxx).  In some cases, it may be possible for the actual line to be in-service,
but there may be congestion in the path to the physical line.  An error code is
needed to report such a case to the MGC (e.g., access facility busy) as a
response to an AddRequest command.

The following command error code should be added to Section 7.3:

      532 Access Facility Busy.


Section 3.4 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
provides a proposal for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:13:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05769
	for ; Thu, 27 Jan 2000 09:13:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.817EBD90@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:11:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11010 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:10:08 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.4EDE3AF0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:10:08
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          JAA23633 for ; Thu, 27 Jan 2000
          09:11:56 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004E00CF ; Thu, 27 Jan 2000 09:12:00 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=qbG6N8zCQMRqQWvuO7NREEuyrY9r7H0C6AYOkDwpHVnTa8BEgjPx9zlM"
Content-Disposition: inline
Message-ID:  <85256873.004DFF5E.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:13:46 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG16: Comments on 8.1.2 regarding ContextIDs in H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=qbG6N8zCQMRqQWvuO7NREEuyrY9r7H0C6AYOkDwpHVnTa8BEgjPx9zlM
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





Section 8.1.2 of H.248 (White Paper, Megaco Version 12) describes uses for only
two of the possible values for contextID: "null
--0__=qbG6N8zCQMRqQWvuO7NREEuyrY9r7H0C6AYOkDwpHVnTa8BEgjPx9zlM
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


? and "unspecified".  Actually,
the protocol [either ASN.1 or ABNF] does not make reference to the use =
of these
values.  It simply indicates how these are coded.  Clear requirements o=
r
guidelines are needed for how each of these is to be used.  For example=
, how is
the "choose" value to be used and how/why is it different than using th=
e
"unspecified" value? Notice that  the "choose" wildcard is used for
TerminationIDs to request the MG to allocate a TerminationID in the cas=
e of an
ephemeral termination.

Since TerminationIDs use a value of "choose" to request the MG to alloc=
ate a
value in the case of an ephemeral termination (i.e., one that does not =
exist),
contextIDs should also use the value of "choose" when requesting the MG=
 to
allocate a value. Section 8.1.2 should be modified so that the word
"unspecified" is replaced with the word "choose".

Section 3.5 of a Telcordia Technologies contribution to SG 16 (which ca=
n be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DO=
C )
provides a proposal for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com






=

--0__=qbG6N8zCQMRqQWvuO7NREEuyrY9r7H0C6AYOkDwpHVnTa8BEgjPx9zlM--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:15:52 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05826
	for ; Thu, 27 Jan 2000 09:15:51 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C98D3E40@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:13:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11019 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:12:35 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.A600BFB0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:12:34
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          JAA23891 for ; Thu, 27 Jan 2000
          09:14:22 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004E38B6 ; Thu, 27 Jan 2000 09:14:23 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004E3691.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:16:08 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG16: CommandError in Annex A of H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In Annex A, the following term "CommandError" is defined, however, it is not
tied to any transaction, action, or command.  It is not clear what its use is.
H.248 should state what its relationship is to the other aspects of the protocol
or should remove it.

It is proposed that the CommandError description in Annex A be removed.

Section 3.6 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
provides a proposal for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:17:50 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05948
	for ; Thu, 27 Jan 2000 09:17:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1196DCF0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:15:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11030 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:14:57 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.FB143A90@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:14:57
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          JAA24088 for ; Thu, 27 Jan 2000
          09:16:45 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004E70A0 ; Thu, 27 Jan 2000 09:16:46 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=A8cfW9LqUH7RvO3SRYhlRbaZCr1YcCvdWW3041Txe04jxhgRXrrhRh6J"
Content-Disposition: inline
Message-ID:  <85256873.004E6FBA.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:18:34 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG16: Additional Notification from the MG to the MGC
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=A8cfW9LqUH7RvO3SRYhlRbaZCr1YcCvdWW3041Txe04jxhgRXrrhRh6J
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline





When an ATM core network connection fails during the active state of a call, how
does the network and call recover from this situation if at all?  Does the MG
notify the MGC of this failure?  Does the MG that initiated the connection
re-attempt the connection to the remote MG or do we wait until the caller or
called party determines that the call has failed and sends a clearing indication
to the network?

Another situation is the MG that is the recipient of the ATM connection request
through the core network (e.g., it receives the ATM SETUP message and responds
with an ATM CONNECT message).  In this case, this MG does not have a way to
inform its serving MGC that the ATM connection has been established.

At least two additional notifications may need to be supported between the MG
and the MGC:


--0__=A8cfW9LqUH7RvO3SRYhlRbaZCr1YcCvdWW3041Txe04jxhgRXrrhRh6J
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


=B7    One notification to inform the MGC that an ATM connection (incom=
ing to the
MG) has been established.

=B7    Another notification to inform the MGC when an ATM connection is=
 released.

Consideration should be given as to exactly how these are to be support=
ed (i.e.,
whether in the base protocol or in a package) although inclusion in the=
 base
protocol is preferred.

Section 3.7 of a Telcordia Technologies contribution to SG 16 (which ca=
n be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DO=
C )
provides a proposal for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com



=

--0__=A8cfW9LqUH7RvO3SRYhlRbaZCr1YcCvdWW3041Txe04jxhgRXrrhRh6J--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:22:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06046
	for ; Thu, 27 Jan 2000 09:22:47 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4EA4DA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:20:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11043 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:18:53 -0500
Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.877C4A40@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:18:53
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id
          JAA25775 for ; Thu, 27 Jan 2000
          09:20:40 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004ECD23 ; Thu, 27 Jan 2000 09:20:43 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004ECC57.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:22:31 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG16: Need for a mechanism to support Caller
              Identification Services in H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

A number of analog lines that subscribe to caller ID services require special
signaling in order for the analog CPE to receive the caller id information from
the network.  In North America, on-hook and off-hook transmission techniques
have been defined, implemented and deployed in the PSTNs that allow a network to
provide such a capability.  Within a VOP network serving analog lines/users, a
similar capability is needed.

Different services can make use of this signaling technique including calling
number identification, calling name identification, visual message waiting
indicator, caller id on call waiting, etc.

ANSI T1.401.03-1998, "Network to Customer Installation Interfaces - Analog
Voicegrade Switched Access Lines with Calling Number Delivery, Calling Name
Delivery or Visual Message Waiting Indicator Features" defines how the
application message is created for these applications.  ANSI T1.401.03 defines
three formats to use for delivery of service information to an analog CPE
namely: Single Data Message Format (SDMF), Multiple Data Message Format (MDMF),
and Generic Data Message Format (GDMF).  SDMF has been historically used for the
delivery of calling number information.  MDMF is used for the delivery of
calling number and calling name information.  GDMF is used for delivery of
service information created by third party applications (e.g., remote server). A
means is needed to deliver that message to the MG for transmission to the CPE.

Within H.248, a new package can be defined to handle this case.


Section 3 of a Telcordia Technologies contribution to SG 16 (which can be found
at ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-callerid.DOC )
provides a proposal for addressing this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 09:31:55 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06322
	for ; Thu, 27 Jan 2000 09:31:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0762CB20@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:29:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11056 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 09:28:25 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.DC8918F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 9:28:25
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          JAA25609 for ; Thu, 27 Jan 2000
          09:30:13 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256873.004FAB78 ; Thu, 27 Jan 2000 09:30:12 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256873.004FAA33.00@notes950.cc.telcordia.com>
Date:         Thu, 27 Jan 2000 09:31:58 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Telcordia SG 16: Questions on Clause 7.1.9 of H.248
X-cc:         "Richard B. Rubin" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This e-mail was accidently sent using a different subject line titled "Telcordia
SG 16: Additional Call Information Needed in H.248".  Please ignore the second
e-mail with the title "Telcordia SG 16: Additional Call Information Needed in
H.248".

I apologize for any confusion this may have caused.

-Selvam

-
-------------------------------------------------------------------------------------
According to Section 7.1.9, can an embedded EventsDescriptor contain an embedded
SignalsDescriptor?

If it can, then the following is possible:  SignalsDescriptor (embedded Events
Descriptor [embedded SignalsDescriptor]). In addition, then the following should
be added to the next to last paragraph of 7.1.9:

An embedded SignalsDescriptor may contain an embedded EventsDescriptor and vice
versa.  However, only two levels of embedding are permitted.  For example, an
embedded EventsDescriptor contained within an embedded Signals Descriptor shall
not itself contain an embedded SignalsDescriptor.

If this is not allowed, then the following should be added to the next to last
paragraph of 7.1.9:

An embedded SignalsDescriptor shall not contain an embedded EventsDescriptor.


Section 3.2 of a Telcordia Technologies contribution to SG 16 (which can be
found at
ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
provides proposals for clarifying this issue.


-Selvam Rengasami
Telcordia Technologies
Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 10:13:01 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07167
	for ; Thu, 27 Jan 2000 10:12:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C35159F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:10:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11092 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 10:09:43 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.A195CAD0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          10:09:43 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 09:10:51 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 10:10:34 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 10:10:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68D8.A7EE2510"
Message-ID:  
Date:         Thu, 27 Jan 2000 10:10:33 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Question about Protocol Version
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68D8.A7EE2510
Content-Type: text/plain

We've been having a quiet debate over whether we should have minor versions
-- it seems rather pointless.  Anyway, it seems reasonable to call this
version 1.  There should be a note to this effect in either section 8.3 or
the syntax annexes.

> -----Original Message-----
> From: Jo Friedman [SMTP:jo@AZTEK-ENG.COM]
> Sent: Tuesday, January 25, 2000 9:58 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Question about Protocol Version
>
> Sorry my question wasn't clear. What I meant to ask is what value is
> assigned to version for the current spec? I.e., should the version in my
> transaction header be 0.1 or 1.0 or ? For example, the MGCP spec has a
> section called "Coding of the protocol version".
>
> Jo
>
> "Rosen, Brian" wrote:
>
>        In every transaction header Brian
>
>               -----Original Message-----
>               From: Jo Friedman [ ]
>               Sent: Monday, January 24, 2000 12:33 PM
>               To: MEGACO@standards.nortelnetworks.com
>               Subject: Re: Question about Protocol Version Negaotiation
>
>               I have a simple, related question. Where is the current
> MEGACO protocol version identified in the spec? Seems like this is
> missing.
>
>               Tom-PT Taylor wrote:
>
>
>
>                       At this point our only backward compatibility
> mechanism is the fallback to earlier version.
>
>                       You make a good point: there is no message by which
> the MG can reject the fallback.  The answer, it seems to me, is that it
> doesn't send one -- it simply doesn't follow up on its original message
> and rejects any command the MGC tries to send it.  If it connected to the
> MGC (e.g. via TCP) it breaks the connection.
>
>                               -----Original Message-----
>                       From:   Qiu Xiuping
> [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
>                       Sent:   Saturday, January 22, 2000 9:51 AM
>                       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>                       Subject:        Question about Protocol Version
> Negaotiation
>
>                               Hi, All.
>
>                               In 11.3 Negotiation of Protocol Version
>
>                               1. The first ServiceChange command from MG
> contains a version number .
>                       2. MGC supports only a lower version, then the MGC
> sends a ServiceChangeReply with the lower version . 3. If the MG is unable
> to comply, it will reject the association, with Error 406 Version Not
> Supported.
>
>                               I wonder what command will MG use in step 3
> .
>                       Will it be notify? but there is no EventDescriptor.
>                       And is it a TransactionRequest , but it is with
> Error code.
>                       IMO, error code is together with TransactionReply
> but not TransactionRequest ?
>
>                               And another question, I remember it says
> that MEGACO/H.248 will be compatible backwards somewhere.
>                       Then  if both MG and MGC use the lower version, why
> there  still exists complying problem.
>
>                               Regards,
>                       Xiuping Qiu
>                       _______________________________________________
>
>                               Xiuping Qiu
>                       Huawei Technologies Co., Ltd.
>                       Mail to   qiuxiuping@sz.huawei.com.cn
>                       Visit     
>                       _______________________________________________
>

------_=_NextPart_001_01BF68D8.A7EE2510
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Question about Protocol Version




        We've been having a =
quiet debate over whether we should have minor versions -- it seems =
rather pointless.  Anyway, it seems reasonable to call this =
version 1.  There should be a note to this effect in either =
section 8.3 or the syntax annexes.
        

          

          -----Original Message-----

          From:   Jo Friedman [SMTP:jo@AZTEK-ENG.COM]

          Sent:   Tuesday, January 25, 2000 9:58 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Question about Protocol =
Version

          


          Sorry my question wasn't clear. What I meant to =
ask is what value is assigned to version for the current spec? I.e., =
should the version in my transaction header be 0.1 or 1.0 or ? For =
example, the MGCP spec has a section called "Coding of the =
protocol version". 
          


          Jo 

          


          "Rosen, Brian" wrote: 

          

            

            =A0In every transaction header=A0Brian 

            

              

              -----Original =
Message-----
              
              From: Jo Friedman [ <mailto:jo@aztek-eng.com><=
/U>]
              
              Sent: Monday, January 24, 2000 12:33 PM
              
              To: =
MEGACO@standards.nortelnetworks.com
              
              Subject: Re: =
Question about Protocol Version Negaotiation
              
=A0              

              I have a simple, related question. Where is =
the current MEGACO protocol version identified in the spec? Seems like =
this is missing. 
              


              Tom-PT Taylor wrote: 

              

                

                =A0 

                


                At this point our =
only backward compatibility mechanism is the fallback to earlier =
version. 

                


                You make a good =
point: there is no message by which the MG can reject the fallback.=A0 =
The answer, it seems to me, is that it doesn't send one -- it simply =
doesn't follow up on its original message and rejects any command the =
MGC tries to send it.=A0 If it connected to the MGC (e.g. via TCP) it =
breaks the connection. 
                


                        -----Original Message-----
                
                From:=A0=A0 Qiu Xiuping =
[SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
                
                Sent:=A0=A0 Saturday, January =
22, 2000 9:51 AM
                
                To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
                
                Subject:=A0=A0=A0=A0=A0=A0=A0 Question about =
Protocol Version Negaotiation 

                


                        Hi, All. 

                


                        In 11.3 Negotiation of Protocol Version 

                


                        1. The first ServiceChange command from MG contains a =
version number .
                
                2. MGC supports only a lower =
version, then the MGC sends a ServiceChangeReply with the lower version =
. 3. If the MG is unable to comply, it will reject the association, =
with Error 406 Version Not Supported. =

                


                        I wonder what command will MG use in step 3 =
.
                
                Will it be notify? but there is no =
EventDescriptor.
                
                And is it a TransactionRequest , =
but it is with Error code.
                
                IMO, error code is together with =
TransactionReply but not TransactionRequest ? 

                


                        And another question, I remember it says that =
MEGACO/H.248 will be compatible backwards somewhere.
                
                Then=A0 if both MG and MGC use the =
lower version, why there=A0 still exists complying problem. 

                


                        Regards,
                
                Xiuping Qiu
                
                _______________________________________________ 

                


                        Xiuping Qiu
                
                Huawei Technologies Co., =
Ltd.
                
                Mail to=A0=A0 =
qiuxiuping@sz.huawei.com.cn
                
                Visit=A0=A0=A0=A0 <http://www.huawei.com.cn>
                
                _______________________________________________

                

        


------_=_NextPart_001_01BF68D8.A7EE2510--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 10:16:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07224
	for ; Thu, 27 Jan 2000 10:16:36 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B5D69A0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:12:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11087 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 10:11:52 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.890B18E0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:01:52
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA20766; Thu, 27 Jan
          2000 10:03:38 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA15156; Thu, 27 Jan
          2000 10:03:16 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 10:00:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208834@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 10:03:12 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Auditing Of Packages
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The Audit Descriptor has DigitMap as one of its options,
so you can ask for a DigitMap.  The text says "DigitMap applied to the root
Termination returns all named DigitMaps in the gateway."
So I AuditValue does what you want.

AuditCapability of DigitMap doesn't make any sense I think, and that is what
the text says.

Packages for ephemerals are solved by name patterns, which was
what started me out on that in the first place.  If you wildcard
auditValue a name pattern that equates to an ephemeral, and ask
for Packages, I think you get a list of packages that ephemeral
would support.

So:
if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
might return
.....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?
n",....}}}}

then
Context=-{W-AuditValue=Ephem*{Audit{Packages}}}

should return the list of packages.

While we could ask that this be made more explicit in the text,
no substantive change is warranted, I believe.

Brian



> -----Original Message-----
> From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> Sent: Wednesday, January 26, 2000 9:23 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Auditing Of Packages
>
>
> Every termination should support digit map capability, so
> digit map names
> and values are all you would want to audit.  AuditValue is
> logical for that.
> This leaves packages, which happen to be tied into what types
> of ephemeral
> termination an MG will support.  Doctrine coming out of
> Washington was that
> you would find out the latter by digging out the termination
> naming pattern,
> then walking through  the naming tree to determine the capabilities
> supported by each branch.  As Chip points out immediately
> below, however,
> you cannot currently determine the packages supported by a
> termination until
> it has been instantiated.  It seems reasonable that
> AuditCapability also
> return a PackageList, the packages potentially supported by
> the termination
> as opposed to those actually invoked.
>
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>
>                     Section:        7.2.6, last line
>                     Category:       Technical
>                     Issue:          The draft text specifies
> that "DigitMap
> and Packages are
>                     not legal in AuditCapability". This is
> inconsistent with
> the return
>                     parameters shown for the example API.
> Furthermore, it
> would seem reasonable
>                     to be able determine what packages a
> termination (or
> gateway) supports as
>                     well as whether digit map is supported or
> not. Although
> packages can be
>                     audited with AuditValue, it would seem to
> make more
> sense to allow it in
>                     AuditCapability.
>                     Proposal:       It is proposed to strike the above
> sentence and allow for
>                     auditing of these two capabilities.
>
>                     v13 Status:     OPEN. No relevant text changed.
>
>                     Section:        7.2.6
>                     Category:       Open Issue
>                     Issue:          The current draft text
> does not specify
> how to audit
>                     ephemerals at startup. This issue was
> identified by the
> IETF editor but has
>                     not yet been resolved (issue 1). The
> issue is, that when
> you boot and have
>                     not yet created any ephemeral
> terminations, how do you
> know what the MG can
>                     do. For example, how do you know if the
> MG has say an IP
> interface, and ATM
>                     interface, an MPLS interface or a Frame
> Relay interface
> . If you could
>                     audit something, you could look at the
> "network" value
> in LocalControl.
>                     Discussion:             A continuation of
> the discussion
> that has occurred
>                     on the Megaco mailing list so far is
> needed in order to
> resolve the issue.
>
>                     v13 Status:     OPEN. No relevant text
> has been added.
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 10:23:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07348
	for ; Thu, 27 Jan 2000 10:23:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2BD7A9B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:20:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11152 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 10:18:47 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4FC79A70@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:14:35
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id VAA29852 for
          ; Thu, 27 Jan 2000 21:14:42
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256873.0053550B ; Thu, 27 Jan 2000 20:40:12 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256873.00535332.00@sandesh.hss.hns.com>
Date:         Thu, 27 Jan 2000 20:43:33 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Optional descriptors
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In case an MG doesn't support multimedia calls, it may not implement Multiplex
Descriptor.
If this is also true for say Modem Descriptor and in a command both these
descriptors
together with other supported descriptor(s) goes to MG. Although it is true that
the command will
fail but there is no way of informing MGC which descriptors are unsupported
"error code - 444"
(Descriptors can be returned only when any value is modified)

Shouldn't we modify the Base ROOT package to support this. Is it that only
toplogy descriptor
is optional?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 11:01:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08218
	for ; Thu, 27 Jan 2000 11:01:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7CA01B20@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:58:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 10:57:19 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D98C79C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:47:04
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA26088; Thu, 27 Jan
          2000 10:48:46 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA26944; Thu, 27 Jan
          2000 10:48:48 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 10:45:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208836@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 10:48:45 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It is legal to move a termination to a new context, but we
wanted to not allow that from null context.

Brian

> -----Original Message-----
> From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
> Sent: Thursday, January 27, 2000 12:59 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Subtract Command with wildcard Termination Name
>
>
>
>
> Agreed that "Choose in a ContextId is create a new one".
> Does this mean that
> in MOVE $ in ContextID is allowed (Move a termination to a
> "new" context)? Or is
> it that
> $ in ContextID is only allowed in case of ADD?
>
> We need to add the following line somewhere in the text:
> "A $ in ContextID means to CREATE a new context and except
> ADD (and MOVE ??)
> it can't appear in any other command"
>
> Regarding ContextID * and $ in Subtract our thinking was:
> 1) ContextID * means "search for a termination in all
> contexts and subtract from
> it"
> 2) ContextId $ means "find the context in which the
> termination exists and
> subtract it from that context"
> By this logical meaning it seems that both are valid. But now
> we agree to what
> you say and (2) is not allowed.
>
>
>
>
>
>
>
>
>
> "Rosen, Brian"  on 01/27/2000 02:38:52 AM
>
> Please respond to "Rosen, Brian" 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Subtract Command with wildcard Termination Name
>
>
>
>
> Just sent a couple of messages that address this:
> Choose in a ContextId is create a new one
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > Sent: Tuesday, January 25, 2000 9:38 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Subtract Command with wildcard Termination Name
> >
> >
> >
> >
> > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
> > that choose
> >  the context  in which the given Termination exist and
> > subtract the termination.
> >
> >
> >
> >
> > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
> >
> > Please respond to "Rosen, Brian" 
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Re: Subtract Command with wildcard Termination Name
> >
> >
> >
> >
> > I think this is headed in the wrong direction.  Subtract of
> wildcarded
> > contextId was explicitly allowed for,
> > among other things, the response to a ServiceChange with mass
> > out of service
> > operations pending.
> > The MGC must subtract all calls, and do it in a hurry.
> >
> > It is also useful in a wildcard Audit, with or without W-.
> >
> > So I think it is allowed, period.
> >
> > Brian
> >
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Monday, January 24, 2000 10:06 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Subtract Command with wildcard Termiantion Name
> >
> >
> >
> > Your question has a couple of wider implications.  My first
> > reaction was to
> > say this was an error, because in principle the MGC can
> > always know which
> > context a termination is in, through audits if necessary.
> > Then I checked
> > out our audit response syntax and realized that the MGC
> > cannot determine the
> > current context of a termination if it doesn't know it already.
> >
> > I think the answer has to be that we change the production
> > auditOther to
> > include the context ID.
> >
> > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
> ContextID
> > terminationAudit RBRKT
> >
> > Then the answer to your original question is that it is an error.
> >
> >         -----Original Message-----
> > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> > Sent:   Sunday, January 23, 2000 11:56 PM
> > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:        Subtract Command with wildcard Termiantion Name
> >
> >         Hi!
> >      Here is a small query regarding the case where ContextID
> > is "*" and
> > Termination Name is fully-specified. Does this implies that
> > MGC intends to
> > Subtract the specific termination from
> > "whichever" context it appears in ? Or it is an error because
> > a termination
> > can
> > exist only in one context and
> > ContextID = "*" for a specific termination is an error ?
> >
> >         Regards
> > MadhuBabu
> >
> >
> >
>
>
>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 11:03:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08267
	for ; Thu, 27 Jan 2000 11:03:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4D4C170@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:00:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11178 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 11:00:09 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.473D87C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 10:50:08
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA26462; Thu, 27 Jan
          2000 10:51:55 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA27793; Thu, 27 Jan
          2000 10:51:57 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 10:48:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208837@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 10:51:55 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: ServiceChange
X-To:         "bmbabu@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I believe the MG should do what the MGC says.

The MGC is responsible for making the state consistent, and this
means getting the Subtract through.

A termination could be out of service, but still in a context,
and would be under failure conditions.  The MGC must run the
Subtract command to get the state reasonable.

If a command other than Subtract (or ServiceChange) was received on a
termination that is out of service, an error should be returned.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@hss.hns.com]
> Sent: Thursday, January 27, 2000 5:00 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: ServiceChange
>
>
> When a termination is marked out-of-service through
> ServiceChange command
> using graceful/ forced ServiceChangeMethod, and MGC has not
> yet sent Subtract
> command for that termination, what is the processing
> associated at MG when
> second
> ServiceChange command arrives with Restart method. Should it
> be removed from
> context or disallow second ServiceChange command?
>
> There is no text in Version 13  mentioning that when
> terminations are brought
> back
> to service using Restart ServiceChange command, what the
> context of the
> terminations
> will be. Version 11 did mention this as "the Termiantions are
> assumed to now not
> be
> associated with any Context".
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 11:23:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09002
	for ; Thu, 27 Jan 2000 11:23:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91F30FC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:20:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11224 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 11:20:42 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.8BA4FCA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:20:41
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          IAA19807; Thu, 27 Jan 2000 08:15:52 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000127110550.00b673d0@dogwood.cisco.com>
Date:         Thu, 27 Jan 2000 11:07:28 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: Auditing Of Packages
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

At 09:23 PM 1/26/00 -0500, Tom-PT Taylor wrote:
>Every termination should support digit map capability, so digit map names
   ^^^^^^^^^^^^^^^^^^^^^
I assume this was a typo?  Do you really mean that every termination (e.g.,
a video termination) should support digit maps?

>and values are all you would want to audit.  AuditValue is logical for that.
>This leaves packages, which happen to be tied into what types of ephemeral
>termination an MG will support.  Doctrine coming out of Washington was that
>you would find out the latter by digging out the termination naming pattern,
>then walking through  the naming tree to determine the capabilities
>supported by each branch.  As Chip points out immediately below, however,
>you cannot currently determine the packages supported by a termination until
>it has been instantiated.  It seems reasonable that AuditCapability also
>return a PackageList, the packages potentially supported by the termination
>as opposed to those actually invoked.
>
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>
>                     Section:        7.2.6, last line
>                     Category:       Technical
>                     Issue:          The draft text specifies that "DigitMap
>and Packages are
>                     not legal in AuditCapability". This is inconsistent with
>the return
>                     parameters shown for the example API. Furthermore, it
>would seem reasonable
>                     to be able determine what packages a termination (or
>gateway) supports as
>                     well as whether digit map is supported or not. Although
>packages can be
>                     audited with AuditValue, it would seem to make more
>sense to allow it in
>                     AuditCapability.
>                     Proposal:       It is proposed to strike the above
>sentence and allow for
>                     auditing of these two capabilities.
>
>                     v13 Status:     OPEN. No relevant text changed.
>
>                     Section:        7.2.6
>                     Category:       Open Issue
>                     Issue:          The current draft text does not specify
>how to audit
>                     ephemerals at startup. This issue was identified by the
>IETF editor but has
>                     not yet been resolved (issue 1). The issue is, that when
>you boot and have
>                     not yet created any ephemeral terminations, how do you
>know what the MG can
>                     do. For example, how do you know if the MG has say an IP
>interface, and ATM
>                     interface, an MPLS interface or a Frame Relay interface
>. If you could
>                     audit something, you could look at the "network" value
>in LocalControl.
>                     Discussion:             A continuation of the discussion
>that has occurred
>                     on the Megaco mailing list so far is needed in order to
>resolve the issue.
>
>                     v13 Status:     OPEN. No relevant text has been added.
>
>Tom Taylor
>Advisor -- IPConnect Standards
>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 11:48:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09494
	for ; Thu, 27 Jan 2000 11:48:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1165AE40@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:45:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11253 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 11:44:32 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E00BDC70@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:44:31
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA24395; Thu, 27 Jan
          2000 08:37:02 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id IAA23473; Thu, 27 Jan 2000 08:44:49 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF208836@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14480.30209.684695.669911@thomasm-u1.cisco.com>
Date:         Thu, 27 Jan 2000 08:44:49 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF208836@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > It is legal to move a termination to a new context, but we
 > wanted to not allow that from null context.

   Why is this? If you allowed it, it seems that
   Add would just be a subset of Move.

          Mike
 >
 > Brian
 >
 > > -----Original Message-----
 > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
 > > Sent: Thursday, January 27, 2000 12:59 AM
 > > To: Rosen, Brian
 > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject: Re: Subtract Command with wildcard Termination Name
 > >
 > >
 > >
 > >
 > > Agreed that "Choose in a ContextId is create a new one".
 > > Does this mean that
 > > in MOVE $ in ContextID is allowed (Move a termination to a
 > > "new" context)? Or is
 > > it that
 > > $ in ContextID is only allowed in case of ADD?
 > >
 > > We need to add the following line somewhere in the text:
 > > "A $ in ContextID means to CREATE a new context and except
 > > ADD (and MOVE ??)
 > > it can't appear in any other command"
 > >
 > > Regarding ContextID * and $ in Subtract our thinking was:
 > > 1) ContextID * means "search for a termination in all
 > > contexts and subtract from
 > > it"
 > > 2) ContextId $ means "find the context in which the
 > > termination exists and
 > > subtract it from that context"
 > > By this logical meaning it seems that both are valid. But now
 > > we agree to what
 > > you say and (2) is not allowed.
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 > >
 > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
 > >
 > > Please respond to "Rosen, Brian" 
 > >
 > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > cc:    (bcc: Sachin Mittal/HSS)
 > >
 > > Subject:  Re: Subtract Command with wildcard Termination Name
 > >
 > >
 > >
 > >
 > > Just sent a couple of messages that address this:
 > > Choose in a ContextId is create a new one
 > >
 > > Brian
 > >
 > > > -----Original Message-----
 > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
 > > > Sent: Tuesday, January 25, 2000 9:38 AM
 > > > To: MEGACO@standards.nortelnetworks.com
 > > > Subject: Re: Subtract Command with wildcard Termination Name
 > > >
 > > >
 > > >
 > > >
 > > > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
 > > > that choose
 > > >  the context  in which the given Termination exist and
 > > > subtract the termination.
 > > >
 > > >
 > > >
 > > >
 > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
 > > >
 > > > Please respond to "Rosen, Brian" 
 > > >
 > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > > cc:    (bcc: Sachin Mittal/HSS)
 > > >
 > > > Subject:  Re: Subtract Command with wildcard Termination Name
 > > >
 > > >
 > > >
 > > >
 > > > I think this is headed in the wrong direction.  Subtract of
 > > wildcarded
 > > > contextId was explicitly allowed for,
 > > > among other things, the response to a ServiceChange with mass
 > > > out of service
 > > > operations pending.
 > > > The MGC must subtract all calls, and do it in a hurry.
 > > >
 > > > It is also useful in a wildcard Audit, with or without W-.
 > > >
 > > > So I think it is allowed, period.
 > > >
 > > > Brian
 > > >
 > > > -----Original Message-----
 > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
 > > > Sent: Monday, January 24, 2000 10:06 AM
 > > > To: MEGACO@standards.nortelnetworks.com
 > > > Subject: Re: Subtract Command with wildcard Termiantion Name
 > > >
 > > >
 > > >
 > > > Your question has a couple of wider implications.  My first
 > > > reaction was to
 > > > say this was an error, because in principle the MGC can
 > > > always know which
 > > > context a termination is in, through audits if necessary.
 > > > Then I checked
 > > > out our audit response syntax and realized that the MGC
 > > > cannot determine the
 > > > current context of a termination if it doesn't know it already.
 > > >
 > > > I think the answer has to be that we change the production
 > > > auditOther to
 > > > include the context ID.
 > > >
 > > > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
 > > ContextID
 > > > terminationAudit RBRKT
 > > >
 > > > Then the answer to your original question is that it is an error.
 > > >
 > > >         -----Original Message-----
 > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
 > > > Sent:   Sunday, January 23, 2000 11:56 PM
 > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > > Subject:        Subtract Command with wildcard Termiantion Name
 > > >
 > > >         Hi!
 > > >      Here is a small query regarding the case where ContextID
 > > > is "*" and
 > > > Termination Name is fully-specified. Does this implies that
 > > > MGC intends to
 > > > Subtract the specific termination from
 > > > "whichever" context it appears in ? Or it is an error because
 > > > a termination
 > > > can
 > > > exist only in one context and
 > > > ContextID = "*" for a specific termination is an error ?
 > > >
 > > >         Regards
 > > > MadhuBabu
 > > >
 > > >
 > > >
 > >
 > >
 > >
 > >
 > >
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:01:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09778
	for ; Thu, 27 Jan 2000 12:01:30 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E3BD12B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:58:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11279 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 11:57:39 -0500
Received: from sj-mailhub-3.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.B5BD8F70@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:57:39
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA10736; Thu, 27
          Jan 2000 09:18:17 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id IAA23479; Thu, 27 Jan 2000 08:59:26 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF208844@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14480.31086.520736.981155@thomasm-u1.cisco.com>
Date:         Thu, 27 Jan 2000 08:59:26 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF208844@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > Can't say I have a really good reason, but I think that two ways
 > to do the same thing are a bad idea.

   Occam's Razor: nuke Add. :-)

           Mike
 >
 > Brian
 >
 > > -----Original Message-----
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > Sent: Thursday, January 27, 2000 11:45 AM
 > > To: Rosen, Brian
 > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject: Re: Subtract Command with wildcard Termination Name
 > >
 > >
 > > Rosen, Brian writes:
 > >  > It is legal to move a termination to a new context, but we
 > >  > wanted to not allow that from null context.
 > >
 > >    Why is this? If you allowed it, it seems that
 > >    Add would just be a subset of Move.
 > >
 > >      Mike
 > >  >
 > >  > Brian
 > >  >
 > >  > > -----Original Message-----
 > >  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
 > >  > > Sent: Thursday, January 27, 2000 12:59 AM
 > >  > > To: Rosen, Brian
 > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > Agreed that "Choose in a ContextId is create a new one".
 > >  > > Does this mean that
 > >  > > in MOVE $ in ContextID is allowed (Move a termination to a
 > >  > > "new" context)? Or is
 > >  > > it that
 > >  > > $ in ContextID is only allowed in case of ADD?
 > >  > >
 > >  > > We need to add the following line somewhere in the text:
 > >  > > "A $ in ContextID means to CREATE a new context and except
 > >  > > ADD (and MOVE ??)
 > >  > > it can't appear in any other command"
 > >  > >
 > >  > > Regarding ContextID * and $ in Subtract our thinking was:
 > >  > > 1) ContextID * means "search for a termination in all
 > >  > > contexts and subtract from
 > >  > > it"
 > >  > > 2) ContextId $ means "find the context in which the
 > >  > > termination exists and
 > >  > > subtract it from that context"
 > >  > > By this logical meaning it seems that both are valid. But now
 > >  > > we agree to what
 > >  > > you say and (2) is not allowed.
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
 > >  > >
 > >  > > Please respond to "Rosen, Brian" 
 > >  > >
 > >  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > >
 > >  > > Subject:  Re: Subtract Command with wildcard Termination Name
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > Just sent a couple of messages that address this:
 > >  > > Choose in a ContextId is create a new one
 > >  > >
 > >  > > Brian
 > >  > >
 > >  > > > -----Original Message-----
 > >  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
 > >  > > > Sent: Tuesday, January 25, 2000 9:38 AM
 > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
 > >  > > > that choose
 > >  > > >  the context  in which the given Termination exist and
 > >  > > > subtract the termination.
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
 > >  > > >
 > >  > > > Please respond to "Rosen, Brian" 
 > >  > > >
 > >  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > > >
 > >  > > > Subject:  Re: Subtract Command with wildcard Termination Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > I think this is headed in the wrong direction.  Subtract of
 > >  > > wildcarded
 > >  > > > contextId was explicitly allowed for,
 > >  > > > among other things, the response to a ServiceChange with mass
 > >  > > > out of service
 > >  > > > operations pending.
 > >  > > > The MGC must subtract all calls, and do it in a hurry.
 > >  > > >
 > >  > > > It is also useful in a wildcard Audit, with or without W-.
 > >  > > >
 > >  > > > So I think it is allowed, period.
 > >  > > >
 > >  > > > Brian
 > >  > > >
 > >  > > > -----Original Message-----
 > >  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
 > >  > > > Sent: Monday, January 24, 2000 10:06 AM
 > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > > > Subject: Re: Subtract Command with wildcard Termiantion Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > Your question has a couple of wider implications.  My first
 > >  > > > reaction was to
 > >  > > > say this was an error, because in principle the MGC can
 > >  > > > always know which
 > >  > > > context a termination is in, through audits if necessary.
 > >  > > > Then I checked
 > >  > > > out our audit response syntax and realized that the MGC
 > >  > > > cannot determine the
 > >  > > > current context of a termination if it doesn't know it already.
 > >  > > >
 > >  > > > I think the answer has to be that we change the production
 > >  > > > auditOther to
 > >  > > > include the context ID.
 > >  > > >
 > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
 > >  > > ContextID
 > >  > > > terminationAudit RBRKT
 > >  > > >
 > >  > > > Then the answer to your original question is that it
 > > is an error.
 > >  > > >
 > >  > > >         -----Original Message-----
 > >  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
 > >  > > > Sent:   Sunday, January 23, 2000 11:56 PM
 > >  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > > Subject:        Subtract Command with wildcard Termiantion Name
 > >  > > >
 > >  > > >         Hi!
 > >  > > >      Here is a small query regarding the case where ContextID
 > >  > > > is "*" and
 > >  > > > Termination Name is fully-specified. Does this implies that
 > >  > > > MGC intends to
 > >  > > > Subtract the specific termination from
 > >  > > > "whichever" context it appears in ? Or it is an error because
 > >  > > > a termination
 > >  > > > can
 > >  > > > exist only in one context and
 > >  > > > ContextID = "*" for a specific termination is an error ?
 > >  > > >
 > >  > > >         Regards
 > >  > > > MadhuBabu
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  >
 > >  >
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:01:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09785
	for ; Thu, 27 Jan 2000 12:01:34 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E425E6A0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:58:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11264 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 11:58:17 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.63D691D0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:48:12
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id LAA02811; Thu, 27 Jan
          2000 11:49:58 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id LAA13127; Thu, 27 Jan
          2000 11:50:00 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 11:46:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208844@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 11:49:58 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Can't say I have a really good reason, but I think that two ways
to do the same thing are a bad idea.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 27, 2000 11:45 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Subtract Command with wildcard Termination Name
>
>
> Rosen, Brian writes:
>  > It is legal to move a termination to a new context, but we
>  > wanted to not allow that from null context.
>
>    Why is this? If you allowed it, it seems that
>    Add would just be a subset of Move.
>
>         Mike
>  >
>  > Brian
>  >
>  > > -----Original Message-----
>  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
>  > > Sent: Thursday, January 27, 2000 12:59 AM
>  > > To: Rosen, Brian
>  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > >
>  > >
>  > > Agreed that "Choose in a ContextId is create a new one".
>  > > Does this mean that
>  > > in MOVE $ in ContextID is allowed (Move a termination to a
>  > > "new" context)? Or is
>  > > it that
>  > > $ in ContextID is only allowed in case of ADD?
>  > >
>  > > We need to add the following line somewhere in the text:
>  > > "A $ in ContextID means to CREATE a new context and except
>  > > ADD (and MOVE ??)
>  > > it can't appear in any other command"
>  > >
>  > > Regarding ContextID * and $ in Subtract our thinking was:
>  > > 1) ContextID * means "search for a termination in all
>  > > contexts and subtract from
>  > > it"
>  > > 2) ContextId $ means "find the context in which the
>  > > termination exists and
>  > > subtract it from that context"
>  > > By this logical meaning it seems that both are valid. But now
>  > > we agree to what
>  > > you say and (2) is not allowed.
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
>  > >
>  > > Please respond to "Rosen, Brian" 
>  > >
>  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > cc:    (bcc: Sachin Mittal/HSS)
>  > >
>  > > Subject:  Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > >
>  > >
>  > > Just sent a couple of messages that address this:
>  > > Choose in a ContextId is create a new one
>  > >
>  > > Brian
>  > >
>  > > > -----Original Message-----
>  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>  > > > Sent: Tuesday, January 25, 2000 9:38 AM
>  > > > To: MEGACO@standards.nortelnetworks.com
>  > > > Subject: Re: Subtract Command with wildcard Termination Name
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
>  > > > that choose
>  > > >  the context  in which the given Termination exist and
>  > > > subtract the termination.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>  > > >
>  > > > Please respond to "Rosen, Brian" 
>  > > >
>  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > > cc:    (bcc: Sachin Mittal/HSS)
>  > > >
>  > > > Subject:  Re: Subtract Command with wildcard Termination Name
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > I think this is headed in the wrong direction.  Subtract of
>  > > wildcarded
>  > > > contextId was explicitly allowed for,
>  > > > among other things, the response to a ServiceChange with mass
>  > > > out of service
>  > > > operations pending.
>  > > > The MGC must subtract all calls, and do it in a hurry.
>  > > >
>  > > > It is also useful in a wildcard Audit, with or without W-.
>  > > >
>  > > > So I think it is allowed, period.
>  > > >
>  > > > Brian
>  > > >
>  > > > -----Original Message-----
>  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>  > > > Sent: Monday, January 24, 2000 10:06 AM
>  > > > To: MEGACO@standards.nortelnetworks.com
>  > > > Subject: Re: Subtract Command with wildcard Termiantion Name
>  > > >
>  > > >
>  > > >
>  > > > Your question has a couple of wider implications.  My first
>  > > > reaction was to
>  > > > say this was an error, because in principle the MGC can
>  > > > always know which
>  > > > context a termination is in, through audits if necessary.
>  > > > Then I checked
>  > > > out our audit response syntax and realized that the MGC
>  > > > cannot determine the
>  > > > current context of a termination if it doesn't know it already.
>  > > >
>  > > > I think the answer has to be that we change the production
>  > > > auditOther to
>  > > > include the context ID.
>  > > >
>  > > > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
>  > > ContextID
>  > > > terminationAudit RBRKT
>  > > >
>  > > > Then the answer to your original question is that it
> is an error.
>  > > >
>  > > >         -----Original Message-----
>  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>  > > > Sent:   Sunday, January 23, 2000 11:56 PM
>  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > > Subject:        Subtract Command with wildcard Termiantion Name
>  > > >
>  > > >         Hi!
>  > > >      Here is a small query regarding the case where ContextID
>  > > > is "*" and
>  > > > Termination Name is fully-specified. Does this implies that
>  > > > MGC intends to
>  > > > Subtract the specific termination from
>  > > > "whichever" context it appears in ? Or it is an error because
>  > > > a termination
>  > > > can
>  > > > exist only in one context and
>  > > > ContextID = "*" for a specific termination is an error ?
>  > > >
>  > > >         Regards
>  > > > MadhuBabu
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
>  >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:09:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09924
	for ; Thu, 27 Jan 2000 12:09:16 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.036C88B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:06:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11308 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:05:54 -0500
Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DC516520@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:05:53
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA05979; Thu, 27 Jan
          2000 08:59:10 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id JAA23482; Thu, 27 Jan 2000 09:07:03 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF208845@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14480.31543.676558.918567@thomasm-u1.cisco.com>
Date:         Thu, 27 Jan 2000 09:07:03 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF208845@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > Not a bad idea, but a little late.

   Sure, but what this says to me is that Move
   should be a proper superset of Add. If Add
   can move something from the null context,
   Move should be able to as well. Essentially,
   Add is just a macro for Move (null, ...).

   Is there some reason why restricting Move is
   a good thing?

          Mike
 >
 > Brian
 >
 > > -----Original Message-----
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > Sent: Thursday, January 27, 2000 11:59 AM
 > > To: Rosen, Brian
 > > Cc: 'Michael Thomas'; 'MEGACO@STANDARDS.NORTELNETWORKS.COM'
 > > Subject: RE: Subtract Command with wildcard Termination Name
 > >
 > >
 > > Rosen, Brian writes:
 > >  > Can't say I have a really good reason, but I think that two ways
 > >  > to do the same thing are a bad idea.
 > >
 > >    Occam's Razor: nuke Add. :-)
 > >
 > >       Mike
 > >  >
 > >  > Brian
 > >  >
 > >  > > -----Original Message-----
 > >  > > From: Michael Thomas [mailto:mat@cisco.com]
 > >  > > Sent: Thursday, January 27, 2000 11:45 AM
 > >  > > To: Rosen, Brian
 > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > >
 > >  > >
 > >  > > Rosen, Brian writes:
 > >  > >  > It is legal to move a termination to a new context, but we
 > >  > >  > wanted to not allow that from null context.
 > >  > >
 > >  > >    Why is this? If you allowed it, it seems that
 > >  > >    Add would just be a subset of Move.
 > >  > >
 > >  > >         Mike
 > >  > >  >
 > >  > >  > Brian
 > >  > >  >
 > >  > >  > > -----Original Message-----
 > >  > >  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
 > >  > >  > > Sent: Thursday, January 27, 2000 12:59 AM
 > >  > >  > > To: Rosen, Brian
 > >  > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > >  > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > > Agreed that "Choose in a ContextId is create a new one".
 > >  > >  > > Does this mean that
 > >  > >  > > in MOVE $ in ContextID is allowed (Move a termination to a
 > >  > >  > > "new" context)? Or is
 > >  > >  > > it that
 > >  > >  > > $ in ContextID is only allowed in case of ADD?
 > >  > >  > >
 > >  > >  > > We need to add the following line somewhere in the text:
 > >  > >  > > "A $ in ContextID means to CREATE a new context and except
 > >  > >  > > ADD (and MOVE ??)
 > >  > >  > > it can't appear in any other command"
 > >  > >  > >
 > >  > >  > > Regarding ContextID * and $ in Subtract our thinking was:
 > >  > >  > > 1) ContextID * means "search for a termination in all
 > >  > >  > > contexts and subtract from
 > >  > >  > > it"
 > >  > >  > > 2) ContextId $ means "find the context in which the
 > >  > >  > > termination exists and
 > >  > >  > > subtract it from that context"
 > >  > >  > > By this logical meaning it seems that both are
 > > valid. But now
 > >  > >  > > we agree to what
 > >  > >  > > you say and (2) is not allowed.
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
 > >  > >  > >
 > >  > >  > > Please respond to "Rosen, Brian" 
 > >  > >  > >
 > >  > >  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > >  > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > >  > >
 > >  > >  > > Subject:  Re: Subtract Command with wildcard
 > > Termination Name
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > > Just sent a couple of messages that address this:
 > >  > >  > > Choose in a ContextId is create a new one
 > >  > >  > >
 > >  > >  > > Brian
 > >  > >  > >
 > >  > >  > > > -----Original Message-----
 > >  > >  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
 > >  > >  > > > Sent: Tuesday, January 25, 2000 9:38 AM
 > >  > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > >  > > > Subject: Re: Subtract Command with wildcard
 > > Termination Name
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC
 > > indicating MG
 > >  > >  > > > that choose
 > >  > >  > > >  the context  in which the given Termination exist and
 > >  > >  > > > subtract the termination.
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
 > >  > >  > > >
 > >  > >  > > > Please respond to "Rosen, Brian" 
 > >  > >  > > >
 > >  > >  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > >  > > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > >  > > >
 > >  > >  > > > Subject:  Re: Subtract Command with wildcard
 > > Termination Name
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > > I think this is headed in the wrong direction.
 > > Subtract of
 > >  > >  > > wildcarded
 > >  > >  > > > contextId was explicitly allowed for,
 > >  > >  > > > among other things, the response to a
 > > ServiceChange with mass
 > >  > >  > > > out of service
 > >  > >  > > > operations pending.
 > >  > >  > > > The MGC must subtract all calls, and do it in a hurry.
 > >  > >  > > >
 > >  > >  > > > It is also useful in a wildcard Audit, with or without W-.
 > >  > >  > > >
 > >  > >  > > > So I think it is allowed, period.
 > >  > >  > > >
 > >  > >  > > > Brian
 > >  > >  > > >
 > >  > >  > > > -----Original Message-----
 > >  > >  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
 > >  > >  > > > Sent: Monday, January 24, 2000 10:06 AM
 > >  > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > >  > > > Subject: Re: Subtract Command with wildcard
 > > Termiantion Name
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > > Your question has a couple of wider implications.
 > >  My first
 > >  > >  > > > reaction was to
 > >  > >  > > > say this was an error, because in principle the MGC can
 > >  > >  > > > always know which
 > >  > >  > > > context a termination is in, through audits if necessary.
 > >  > >  > > > Then I checked
 > >  > >  > > > out our audit response syntax and realized that the MGC
 > >  > >  > > > cannot determine the
 > >  > >  > > > current context of a termination if it doesn't
 > > know it already.
 > >  > >  > > >
 > >  > >  > > > I think the answer has to be that we change the production
 > >  > >  > > > auditOther to
 > >  > >  > > > include the context ID.
 > >  > >  > > >
 > >  > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT
 > > CtxToken EQUAL
 > >  > >  > > ContextID
 > >  > >  > > > terminationAudit RBRKT
 > >  > >  > > >
 > >  > >  > > > Then the answer to your original question is that it
 > >  > > is an error.
 > >  > >  > > >
 > >  > >  > > >         -----Original Message-----
 > >  > >  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
 > >  > >  > > > Sent:   Sunday, January 23, 2000 11:56 PM
 > >  > >  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > >  > > > Subject:        Subtract Command with wildcard
 > > Termiantion Name
 > >  > >  > > >
 > >  > >  > > >         Hi!
 > >  > >  > > >      Here is a small query regarding the case
 > > where ContextID
 > >  > >  > > > is "*" and
 > >  > >  > > > Termination Name is fully-specified. Does this
 > > implies that
 > >  > >  > > > MGC intends to
 > >  > >  > > > Subtract the specific termination from
 > >  > >  > > > "whichever" context it appears in ? Or it is an
 > > error because
 > >  > >  > > > a termination
 > >  > >  > > > can
 > >  > >  > > > exist only in one context and
 > >  > >  > > > ContextID = "*" for a specific termination is an error ?
 > >  > >  > > >
 > >  > >  > > >         Regards
 > >  > >  > > > MadhuBabu
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  > >
 > >  > >  >
 > >  > >  >
 > >  > >
 > >  >
 > >  >
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:13:39 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10037
	for ; Thu, 27 Jan 2000 12:13:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93896300@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:11:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11289 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:09:10 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.EBB5EFA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 11:59:10
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id MAA04049; Thu, 27 Jan
          2000 12:00:48 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id MAA15937; Thu, 27 Jan
          2000 12:00:50 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 11:57:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208845@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 12:00:48 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Not a bad idea, but a little late.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 27, 2000 11:59 AM
> To: Rosen, Brian
> Cc: 'Michael Thomas'; 'MEGACO@STANDARDS.NORTELNETWORKS.COM'
> Subject: RE: Subtract Command with wildcard Termination Name
>
>
> Rosen, Brian writes:
>  > Can't say I have a really good reason, but I think that two ways
>  > to do the same thing are a bad idea.
>
>    Occam's Razor: nuke Add. :-)
>
>          Mike
>  >
>  > Brian
>  >
>  > > -----Original Message-----
>  > > From: Michael Thomas [mailto:mat@cisco.com]
>  > > Sent: Thursday, January 27, 2000 11:45 AM
>  > > To: Rosen, Brian
>  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > > Rosen, Brian writes:
>  > >  > It is legal to move a termination to a new context, but we
>  > >  > wanted to not allow that from null context.
>  > >
>  > >    Why is this? If you allowed it, it seems that
>  > >    Add would just be a subset of Move.
>  > >
>  > >    Mike
>  > >  >
>  > >  > Brian
>  > >  >
>  > >  > > -----Original Message-----
>  > >  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
>  > >  > > Sent: Thursday, January 27, 2000 12:59 AM
>  > >  > > To: Rosen, Brian
>  > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > Agreed that "Choose in a ContextId is create a new one".
>  > >  > > Does this mean that
>  > >  > > in MOVE $ in ContextID is allowed (Move a termination to a
>  > >  > > "new" context)? Or is
>  > >  > > it that
>  > >  > > $ in ContextID is only allowed in case of ADD?
>  > >  > >
>  > >  > > We need to add the following line somewhere in the text:
>  > >  > > "A $ in ContextID means to CREATE a new context and except
>  > >  > > ADD (and MOVE ??)
>  > >  > > it can't appear in any other command"
>  > >  > >
>  > >  > > Regarding ContextID * and $ in Subtract our thinking was:
>  > >  > > 1) ContextID * means "search for a termination in all
>  > >  > > contexts and subtract from
>  > >  > > it"
>  > >  > > 2) ContextId $ means "find the context in which the
>  > >  > > termination exists and
>  > >  > > subtract it from that context"
>  > >  > > By this logical meaning it seems that both are
> valid. But now
>  > >  > > we agree to what
>  > >  > > you say and (2) is not allowed.
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
>  > >  > >
>  > >  > > Please respond to "Rosen, Brian" 
>  > >  > >
>  > >  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > cc:    (bcc: Sachin Mittal/HSS)
>  > >  > >
>  > >  > > Subject:  Re: Subtract Command with wildcard
> Termination Name
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > Just sent a couple of messages that address this:
>  > >  > > Choose in a ContextId is create a new one
>  > >  > >
>  > >  > > Brian
>  > >  > >
>  > >  > > > -----Original Message-----
>  > >  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>  > >  > > > Sent: Tuesday, January 25, 2000 9:38 AM
>  > >  > > > To: MEGACO@standards.nortelnetworks.com
>  > >  > > > Subject: Re: Subtract Command with wildcard
> Termination Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC
> indicating MG
>  > >  > > > that choose
>  > >  > > >  the context  in which the given Termination exist and
>  > >  > > > subtract the termination.
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>  > >  > > >
>  > >  > > > Please respond to "Rosen, Brian" 
>  > >  > > >
>  > >  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > > cc:    (bcc: Sachin Mittal/HSS)
>  > >  > > >
>  > >  > > > Subject:  Re: Subtract Command with wildcard
> Termination Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > I think this is headed in the wrong direction.
> Subtract of
>  > >  > > wildcarded
>  > >  > > > contextId was explicitly allowed for,
>  > >  > > > among other things, the response to a
> ServiceChange with mass
>  > >  > > > out of service
>  > >  > > > operations pending.
>  > >  > > > The MGC must subtract all calls, and do it in a hurry.
>  > >  > > >
>  > >  > > > It is also useful in a wildcard Audit, with or without W-.
>  > >  > > >
>  > >  > > > So I think it is allowed, period.
>  > >  > > >
>  > >  > > > Brian
>  > >  > > >
>  > >  > > > -----Original Message-----
>  > >  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>  > >  > > > Sent: Monday, January 24, 2000 10:06 AM
>  > >  > > > To: MEGACO@standards.nortelnetworks.com
>  > >  > > > Subject: Re: Subtract Command with wildcard
> Termiantion Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > Your question has a couple of wider implications.
>  My first
>  > >  > > > reaction was to
>  > >  > > > say this was an error, because in principle the MGC can
>  > >  > > > always know which
>  > >  > > > context a termination is in, through audits if necessary.
>  > >  > > > Then I checked
>  > >  > > > out our audit response syntax and realized that the MGC
>  > >  > > > cannot determine the
>  > >  > > > current context of a termination if it doesn't
> know it already.
>  > >  > > >
>  > >  > > > I think the answer has to be that we change the production
>  > >  > > > auditOther to
>  > >  > > > include the context ID.
>  > >  > > >
>  > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT
> CtxToken EQUAL
>  > >  > > ContextID
>  > >  > > > terminationAudit RBRKT
>  > >  > > >
>  > >  > > > Then the answer to your original question is that it
>  > > is an error.
>  > >  > > >
>  > >  > > >         -----Original Message-----
>  > >  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>  > >  > > > Sent:   Sunday, January 23, 2000 11:56 PM
>  > >  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > > Subject:        Subtract Command with wildcard
> Termiantion Name
>  > >  > > >
>  > >  > > >         Hi!
>  > >  > > >      Here is a small query regarding the case
> where ContextID
>  > >  > > > is "*" and
>  > >  > > > Termination Name is fully-specified. Does this
> implies that
>  > >  > > > MGC intends to
>  > >  > > > Subtract the specific termination from
>  > >  > > > "whichever" context it appears in ? Or it is an
> error because
>  > >  > > > a termination
>  > >  > > > can
>  > >  > > > exist only in one context and
>  > >  > > > ContextID = "*" for a specific termination is an error ?
>  > >  > > >
>  > >  > > >         Regards
>  > >  > > > MadhuBabu
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  >
>  > >  >
>  > >
>  >
>  >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:40:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10470
	for ; Thu, 27 Jan 2000 12:40:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B9276E0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:38:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11371 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:36:23 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.1E861B80@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:36:22 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:36:42 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 12:36:11 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:36:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68EC.FEF9305C"
Message-ID:  
Date:         Thu, 27 Jan 2000 12:36:08 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Auditing Of Packages
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68EC.FEF9305C
Content-Type: text/plain;
        charset="iso-8859-1"

Terminations in themselves are media-independent.  Hence in principle they
should all support digit maps.  The events which get mapped into digit maps
may be associated with specific media, as indicated by the relevant
packages.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@cisco.com]
> Sent: Thursday, January 27, 2000 11:07 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Auditing Of Packages
>
> At 09:23 PM 1/26/00 -0500, Tom-PT Taylor wrote:
> >Every termination should support digit map capability, so digit map names
>    ^^^^^^^^^^^^^^^^^^^^^
> I assume this was a typo?  Do you really mean that every termination
> (e.g.,
> a video termination) should support digit maps?
>
> >and values are all you would want to audit.  AuditValue is logical for
> that.
> >This leaves packages, which happen to be tied into what types of
> ephemeral
> >termination an MG will support.  Doctrine coming out of Washington was
> that
> >you would find out the latter by digging out the termination naming
> pattern,
> >then walking through  the naming tree to determine the capabilities
> >supported by each branch.  As Chip points out immediately below, however,
> >you cannot currently determine the packages supported by a termination
> until
> >it has been instantiated.  It seems reasonable that AuditCapability also
> >return a PackageList, the packages potentially supported by the
> termination
> >as opposed to those actually invoked.
> >
> >
> >                     From:         Chip Sharp 
> >                     Subject:      Auditing
> >
> >                     Section:        7.2.6, last line
> >                     Category:       Technical
> >                     Issue:          The draft text specifies that
> "DigitMap
> >and Packages are
> >                     not legal in AuditCapability". This is inconsistent
> with
> >the return
> >                     parameters shown for the example API. Furthermore,
> it
> >would seem reasonable
> >                     to be able determine what packages a termination (or
> >gateway) supports as
> >                     well as whether digit map is supported or not.
> Although
> >packages can be
> >                     audited with AuditValue, it would seem to make more
> >sense to allow it in
> >                     AuditCapability.
> >                     Proposal:       It is proposed to strike the above
> >sentence and allow for
> >                     auditing of these two capabilities.
> >
> >                     v13 Status:     OPEN. No relevant text changed.
> >
> >                     Section:        7.2.6
> >                     Category:       Open Issue
> >                     Issue:          The current draft text does not
> specify
> >how to audit
> >                     ephemerals at startup. This issue was identified by
> the
> >IETF editor but has
> >                     not yet been resolved (issue 1). The issue is, that
> when
> >you boot and have
> >                     not yet created any ephemeral terminations, how do
> you
> >know what the MG can
> >                     do. For example, how do you know if the MG has say
> an IP
> >interface, and ATM
> >                     interface, an MPLS interface or a Frame Relay
> interface
> >. If you could
> >                     audit something, you could look at the "network"
> value
> >in LocalControl.
> >                     Discussion:             A continuation of the
> discussion
> >that has occurred
> >                     on the Megaco mailing list so far is needed in order
> to
> >resolve the issue.
> >
> >                     v13 Status:     OPEN. No relevant text has been
> added.
> >
> >Tom Taylor
> >Advisor -- IPConnect Standards
> >E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> >Phone and FAX: +1 613 736 0961
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

------_=_NextPart_001_01BF68EC.FEF9305C
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Auditing Of Packages




        Terminations in =
themselves are media-independent.  Hence in principle they should =
all support digit maps.  The events which get mapped into digit =
maps may be associated with specific media, as indicated by the =
relevant packages.
        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@cisco.com]

          Sent:   Thursday, January 27, 2000 11:07 AM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Auditing Of Packages

          


          At 09:23 PM 1/26/00 -0500, Tom-PT =
Taylor wrote:

          >Every termination should support =
digit map capability, so digit map names

             =
^^^^^^^^^^^^^^^^^^^^^

          I assume this was a typo?  Do =
you really mean that every termination (e.g., 

          a video termination) should support =
digit maps?

          


          >and values are all you would want =
to audit.  AuditValue is logical for that.

          >This leaves packages, which =
happen to be tied into what types of ephemeral

          >termination an MG will =
support.  Doctrine coming out of Washington was that

          >you would find out the latter by =
digging out the termination naming pattern,

          >then walking through  the =
naming tree to determine the capabilities

          >supported by each branch.  =
As Chip points out immediately below, however,

          >you cannot currently determine =
the packages supported by a termination until

          >it has been instantiated.  =
It seems reasonable that AuditCapability also

          >return a PackageList, the =
packages potentially supported by the termination

          >as opposed to those actually =
invoked.

          >

          >

          >         =
;            =
From:         Chip Sharp =
<chsharp@CISCO.COM>

          >         =
;            =
Subject:      Auditing

          >

          >         =
;            =
Section:        7.2.6, last =
line

          >         =
;            =
Category:       Technical

          >         =
;            =
Issue:          The draft =
text specifies that "DigitMap

          >and Packages are

          >         =
;            not =
legal in AuditCapability". This is inconsistent with

          >the return

          >         =
;            =
parameters shown for the example API. Furthermore, it

          >would seem reasonable

          >         =
;            to =
be able determine what packages a termination (or

          >gateway) supports as

          >         =
;            =
well as whether digit map is supported or not. Although

          >packages can be

          >         =
;            =
audited with AuditValue, it would seem to make more

          >sense to allow it in

          >         =
;            =
AuditCapability.

          >         =
;            =
Proposal:       It is proposed to strike =
the above

          >sentence and allow for

          >         =
;            =
auditing of these two capabilities.

          >

          >         =
;            v13 =
Status:     OPEN. No relevant text changed.

          >

          >         =
;            =
Section:        7.2.6

          >         =
;            =
Category:       Open Issue

          >         =
;            =
Issue:          The =
current draft text does not specify

          >how to audit

          >         =
;            =
ephemerals at startup. This issue was identified by the

          >IETF editor but has

          >         =
;            not =
yet been resolved (issue 1). The issue is, that when

          >you boot and have

          >         =
;            not =
yet created any ephemeral terminations, how do you

          >know what the MG can

          >         =
;            do. =
For example, how do you know if the MG has say an IP

          >interface, and ATM

          >         =
;            =
interface, an MPLS interface or a Frame Relay interface

          >. If you could

          >         =
;            =
audit something, you could look at the "network" value

          >in LocalControl.

          >         =
;            =
Discussion:          &=
nbsp;  A continuation of the discussion

          >that has occurred

          >         =
;            on =
the Megaco mailing list so far is needed in order to

          >resolve the issue.

          >

          >         =
;            v13 =
Status:     OPEN. No relevant text has been =
added.

          >

          >Tom Taylor

          >Advisor -- IPConnect =
Standards

          >E-mail: taylor@nortelnetworks.com =
(internally, Tom-PT Taylor)

          >Phone and FAX: +1 613 736 =
0961

          


          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.  =
        =
        

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF68EC.FEF9305C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:43:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10534
	for ; Thu, 27 Jan 2000 12:43:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A39E8690@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:40:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11380 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:38:28 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.69054E10@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:38:27 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:39:12 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 12:38:56 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:38:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68ED.6124E42E"
Message-ID:  
Date:         Thu, 27 Jan 2000 12:38:53 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Auditing Of Packages
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68ED.6124E42E
Content-Type: text/plain;
        charset="iso-8859-1"

You miss the point.  When an MG first starts up, there are no instantiated
ephemeral terminations.  As a result, you can't do an AuditValue on them.
It HAS to be AuditCapability.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Thursday, January 27, 2000 10:03 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Auditing Of Packages
>
> The Audit Descriptor has DigitMap as one of its options,
> so you can ask for a DigitMap.  The text says "DigitMap applied to the
> root
> Termination returns all named DigitMaps in the gateway."
> So I AuditValue does what you want.
>
> AuditCapability of DigitMap doesn't make any sense I think, and that is
> what
> the text says.
>
> Packages for ephemerals are solved by name patterns, which was
> what started me out on that in the first place.  If you wildcard
> auditValue a name pattern that equates to an ephemeral, and ask
> for Packages, I think you get a list of packages that ephemeral
> would support.
>
> So:
> if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
> might return
> .....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?
> n?
> n",....}}}}
>
> then
> Context=-{W-AuditValue=Ephem*{Audit{Packages}}}
>
> should return the list of packages.
>
> While we could ask that this be made more explicit in the text,
> no substantive change is warranted, I believe.
>
> Brian
>
>
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
> > Sent: Wednesday, January 26, 2000 9:23 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Auditing Of Packages
> >
> >
> > Every termination should support digit map capability, so
> > digit map names
> > and values are all you would want to audit.  AuditValue is
> > logical for that.
> > This leaves packages, which happen to be tied into what types
> > of ephemeral
> > termination an MG will support.  Doctrine coming out of
> > Washington was that
> > you would find out the latter by digging out the termination
> > naming pattern,
> > then walking through  the naming tree to determine the capabilities
> > supported by each branch.  As Chip points out immediately
> > below, however,
> > you cannot currently determine the packages supported by a
> > termination until
> > it has been instantiated.  It seems reasonable that
> > AuditCapability also
> > return a PackageList, the packages potentially supported by
> > the termination
> > as opposed to those actually invoked.
> >
> >
> >                     From:         Chip Sharp 
> >                     Subject:      Auditing
> >
> >                     Section:        7.2.6, last line
> >                     Category:       Technical
> >                     Issue:          The draft text specifies
> > that "DigitMap
> > and Packages are
> >                     not legal in AuditCapability". This is
> > inconsistent with
> > the return
> >                     parameters shown for the example API.
> > Furthermore, it
> > would seem reasonable
> >                     to be able determine what packages a
> > termination (or
> > gateway) supports as
> >                     well as whether digit map is supported or
> > not. Although
> > packages can be
> >                     audited with AuditValue, it would seem to
> > make more
> > sense to allow it in
> >                     AuditCapability.
> >                     Proposal:       It is proposed to strike the above
> > sentence and allow for
> >                     auditing of these two capabilities.
> >
> >                     v13 Status:     OPEN. No relevant text changed.
> >
> >                     Section:        7.2.6
> >                     Category:       Open Issue
> >                     Issue:          The current draft text
> > does not specify
> > how to audit
> >                     ephemerals at startup. This issue was
> > identified by the
> > IETF editor but has
> >                     not yet been resolved (issue 1). The
> > issue is, that when
> > you boot and have
> >                     not yet created any ephemeral
> > terminations, how do you
> > know what the MG can
> >                     do. For example, how do you know if the
> > MG has say an IP
> > interface, and ATM
> >                     interface, an MPLS interface or a Frame
> > Relay interface
> > . If you could
> >                     audit something, you could look at the
> > "network" value
> > in LocalControl.
> >                     Discussion:             A continuation of
> > the discussion
> > that has occurred
> >                     on the Megaco mailing list so far is
> > needed in order to
> > resolve the issue.
> >
> >                     v13 Status:     OPEN. No relevant text
> > has been added.
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

------_=_NextPart_001_01BF68ED.6124E42E
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Auditing Of Packages




        You miss the =
point.  When an MG first starts up, there are no instantiated =
ephemeral terminations.  As a result, you can't do an AuditValue =
on them.  It HAS to be AuditCapability.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Thursday, January 27, 2000 10:03 AM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Auditing Of Packages

          


          The Audit Descriptor has DigitMap as =
one of its options,

          so you can ask for a DigitMap.  =
The text says "DigitMap applied to the root

          Termination returns all named =
DigitMaps in the gateway."

          So I AuditValue does what you =
want.

          


          AuditCapability of DigitMap doesn't =
make any sense I think, and that is what

          the text says.

          


          Packages for ephemerals are solved by =
name patterns, which was

          what started me out on that in the =
first place.  If you wildcard 

          auditValue a name pattern that =
equates to an ephemeral, and ask

          for Packages, I think you get a list =
of packages that ephemeral

          would support.

          


          So:

          if =
Context=3D-{Modify=3DRoot{TerminationState{g/PatternNum=3D2}}}

          might return

          .....TerminationState(g/MaxPatterns=3D4,g/PatternNum=3D2,=
g/Pattern=3D"Ephem?n?n?n?

          n",....}}}}

          


          then

          Context=3D-{W-AuditValue=3DEphem*{Audit{Packages}}}

          


          should return the list of =
packages.

          


          While we could ask that this be made =
more explicit in the text,

          no substantive change is warranted, I =
believe.  

          


          Brian

          

          

          


          > -----Original Message-----

          > From: Tom-PT Taylor =
[mailto:taylor@nortelnetworks.c=
om]

          > Sent: Wednesday, January 26, =
2000 9:23 PM

          > To: =
MEGACO@standards.nortelnetworks.com

          > Subject: Auditing Of =
Packages

          > 

          > 

          > Every termination should support =
digit map capability, so 

          > digit map names

          > and values are all you would =
want to audit.  AuditValue is 

          > logical for that.

          > This leaves packages, which =
happen to be tied into what types 

          > of ephemeral

          > termination an MG will =
support.  Doctrine coming out of 

          > Washington was that

          > you would find out the latter by =
digging out the termination 

          > naming pattern,

          > then walking through  the =
naming tree to determine the capabilities

          > supported by each branch.  =
As Chip points out immediately 

          > below, however,

          > you cannot currently determine =
the packages supported by a 

          > termination until

          > it has been instantiated.  =
It seems reasonable that 

          > AuditCapability also

          > return a PackageList, the =
packages potentially supported by 

          > the termination

          > as opposed to those actually =
invoked.

          > 

          > 

          >         =
;            =
From:         Chip Sharp =
<chsharp@CISCO.COM>

          >         =
;            =
Subject:      Auditing

          > 

          >         =
;            =
Section:        7.2.6, last =
line

          >         =
;            =
Category:       Technical

          >         =
;            =
Issue:          The draft =
text specifies 

          > that "DigitMap

          > and Packages are

          >         =
;            not =
legal in AuditCapability". This is 

          > inconsistent with

          > the return

          >         =
;            =
parameters shown for the example API. 

          > Furthermore, it

          > would seem reasonable

          >         =
;            to =
be able determine what packages a 

          > termination (or

          > gateway) supports as

          >         =
;            =
well as whether digit map is supported or 

          > not. Although

          > packages can be

          >         =
;            =
audited with AuditValue, it would seem to 

          > make more

          > sense to allow it in

          >         =
;            =
AuditCapability.

          >         =
;            =
Proposal:       It is proposed to strike =
the above

          > sentence and allow for

          >         =
;            =
auditing of these two capabilities.

          > 

          >         =
;            v13 =
Status:     OPEN. No relevant text changed.

          > 

          >         =
;            =
Section:        7.2.6

          >         =
;            =
Category:       Open Issue

          >         =
;            =
Issue:          The =
current draft text 

          > does not specify

          > how to audit

          >         =
;            =
ephemerals at startup. This issue was 

          > identified by the

          > IETF editor but has

          >         =
;            not =
yet been resolved (issue 1). The 

          > issue is, that when

          > you boot and have

          >         =
;            not =
yet created any ephemeral 

          > terminations, how do you

          > know what the MG can

          >         =
;            do. =
For example, how do you know if the 

          > MG has say an IP

          > interface, and ATM

          >         =
;            =
interface, an MPLS interface or a Frame 

          > Relay interface

          > . If you could

          >         =
;            =
audit something, you could look at the 

          > "network" value

          > in LocalControl.

          >         =
;            =
Discussion:          &=
nbsp;  A continuation of 

          > the discussion

          > that has occurred

          >         =
;            on =
the Megaco mailing list so far is 

          > needed in order to

          > resolve the issue.

          > 

          >         =
;            v13 =
Status:     OPEN. No relevant text 

          > has been added.

          > 

          > Tom Taylor

          > Advisor -- IPConnect =
Standards

          > E-mail: =
taylor@nortelnetworks.com (internally, Tom-PT Taylor)

          > Phone and FAX: +1 613 736 =
0961

          > 

          

        


------_=_NextPart_001_01BF68ED.6124E42E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:43:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10544
	for ; Thu, 27 Jan 2000 12:43:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A3EF8CC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:40:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11385 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:38:28 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.692DBDA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:38:28 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:40:01 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 12:39:41
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 11:39:37 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68ED.79D71A82"
Message-ID:  
Date:         Thu, 27 Jan 2000 11:39:36 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68ED.79D71A82
Content-Type: text/plain

I'll consider this one closed based on your and Brian's solutions.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Tuesday, January 25, 2000 10:27 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Subtract Command with wildcard Termination Name
>
> Is the following what you want to do?
>
> Transaction=1000{Context=*{AuditValue=T123}}
> Reply = 1000{Context=2222{AuditValue=Context{T123}}
>
> or
>
> Transaction=1000{Context=*{AuditValue=*}}
> Reply = 1000{Context=2222{AuditValue=Context{T123},
>                          Context=3333{AuditValue=Context{T222,T333},
>                          Context=.....}
>
> If yes, this is already taken into account by the current ABNF.
>
> Chuong
>
> Tom-PT Taylor wrote:
>
>
>
>       OK, this is the second comment I've had to this effect -- the other
> was received privately.  The one question is whether we want a way to find
> out what context a termination is in without subtracting it to find out,
> in which case the audit response syntax I suggested might be considered.
> Silence means we don't need this additional functiuonality.
>
>               -----Original Message-----
>       From:  Rosen, Brian [SMTP:brosen@fore.com]
>       Sent:  Monday, January 24, 2000 10:10 PM
>       To:    Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@standards.nortelnetworks.com
>       Subject:       RE: Subtract Command with wildcard Termination Name
>
>               I think this is headed in the wrong direction.  Subtract of
> wildcarded contextId was explicitly allowed for,
>       among other things, the response to a ServiceChange with mass out of
> service operations pending.
>       The MGC must subtract all calls, and do it in a hurry.
>
>               It is also useful in a wildcard Audit, with or without W-.
>
>               So I think it is allowed, period.
>
>               Brian
>
>                       -----Original Message-----
>               From: Tom-PT Taylor [ ]
>               Sent: Monday, January 24, 2000 10:06 AM
>               To: MEGACO@standards.nortelnetworks.com
>               Subject: Re: Subtract Command with wildcard Termiantion Name
>
>
>
>                       Your question has a couple of wider implications.
> My first reaction was to say this was an error, because in principle the
> MGC can always know which context a termination is in, through audits if
> necessary.  Then I checked out our audit response syntax and realized that
> the MGC cannot determine the current context of a termination if it
> doesn't know it already.
>
>                       I think the answer has to be that we change the
> production auditOther to include the context ID.
>
>                       e.g.auditOther = EQUAL TerminationID LBRKT  CtxToken
> EQUAL ContextID  terminationAudit RBRKT
>
>                       Then the answer to your original question is that it
> is an error.
>
>                               -----Original Message-----
>               From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>               Sent:   Sunday, January 23, 2000 11:56 PM
>               To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject:       Subtract Command with wildcard Termiantion
> Name
>
>                               Hi!
>                    Here is a small query regarding the case where
> ContextID is "*" and
>               Termination Name is fully-specified. Does this implies that
> MGC intends to
>               Subtract the specific termination from
>               "whichever" context it appears in ? Or it is an error
> because a termination can
>               exist only in one context and
>               ContextID = "*" for a specific termination is an error ?
>
>                               Regards
>               MadhuBabu
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

------_=_NextPart_001_01BF68ED.79D71A82
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Subtract Command with wildcard Termination Name




        I'll consider this =
one closed based on your and Brian's solutions.

        

          

          -----Original Message-----

          From:   Chuong Nguyen =
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]

          Sent:   Tuesday, January 25, 2000 10:27 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Subtract Command with wildcard =
Termination Name

          


          Is the following what you want to do? 

          


          Transaction=3D1000{Context=3D*{AuditValue=3DT123}}
          
Reply =3D 1000{Context=3D2222{AuditValue=3DContext{T123}}           

          


          or 

          


          Transaction=3D1000{Context=3D*{AuditValue=3D*}}
          
Reply =3D 1000{Context=3D2222{AuditValue=3DContext{T123},
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Context=3D3333{AuditValue=3DContext{T222,T333},
          
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 Context=3D.....}           

          


          If yes, this is already taken into account by =
the current ABNF. 

          


          Chuong 

          


          Tom-PT Taylor wrote: 

          

            

            =A0 

            


            OK, this is the =
second comment I've had to this effect -- the other was received =
privately.=A0 The one question is whether we want a way to find out =
what context a termination is in without subtracting it to find out, in =
which case the audit response syntax I suggested might be =
considered.=A0 Silence means we don't need this additional =
functiuonality. 
            


                    -----Original Message-----
            
            From:=A0 Rosen, Brian [SMTP:brosen@fore.com]
            
            Sent:=A0 Monday, January 24, 2000 10:10 PM
            
            To:=A0=A0=A0 Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com
            
            Subject:=A0=A0=A0=A0=A0=A0 RE: Subtract Command with wildcard Termination =
Name 

            


                    I think this is headed in the wrong =
direction.=A0 Subtract of wildcarded contextId was explicitly allowed =
for,
            
            among other =
things, the response to a ServiceChange with mass out of service =
operations pending.
            
            The MGC must =
subtract all calls, and do it in a hurry. =


            


                    It is also useful in a wildcard Audit, with or =
without W-. 

            


                    So I think it is allowed, period. 

            


                    Brian 

            

              

                      -----Original Message-----
              
              From: Tom-PT Taylor [ <mailto:taylor@nortelnetworks.c=
om>]
              
              Sent: Monday, January 24, 2000 10:06 AM
              
              To: =
MEGACO@standards.nortelnetworks.com
              
              Subject: Re: =
Subtract Command with wildcard Termiantion Name
              
=A0               

              


                      Your question has a couple of wider =
implications.=A0 My first reaction was to say this was an error, =
because in principle the MGC can always know which context a =
termination is in, through audits if necessary.=A0 Then I checked out =
our audit response syntax and realized that the MGC cannot determine =
the current context of a termination if it doesn't know it =
already. 
              


                      I think the answer has to be that we change the =
production auditOther to include the context ID. 

              


                      e.g.auditOther =3D EQUAL TerminationID LBRKT=A0 CtxToken EQUAL =
ContextID=A0 terminationAudit RBRKT 

              


                      Then the answer to your original question is =
that it is an error. 

              


                      =A0=A0=A0=A0=A0=A0=A0 -----Original Message-----
              
              From:=A0=A0 Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]
              
              Sent:=A0=A0 Sunday, January =
23, 2000 11:56 PM
              
              To:=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
              
              Subject:=A0=A0=A0=A0=A0=A0 Subtract Command with wildcard Termiantion =
Name 

              


                      =A0=A0=A0=A0=A0=A0=A0 Hi!
              
              =A0=A0=A0=A0 Here is a small query =
regarding the case where ContextID is "*" and
              
              Termination Name is =
fully-specified. Does this implies that MGC intends to
              
              Subtract the specific termination =
from
              
              "whichever" context it =
appears in ? Or it is an error because a termination can
              
              exist only in one context =
and
              
              ContextID =3D "*" for a =
specific termination is an error ? 

              


                      =A0=A0=A0=A0=A0=A0=A0 Regards
              
              MadhuBabu

              

          

          --=A0
          
=A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: =
Chuong.Nguyen@usa.alcatel.com
          
=A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Phone:=A0=A0=A0 (972) 519-4613
          
=A0 **** The opinions expressed are not those of Alcatel USA, Inc =
****          

          =A0

          

        


------_=_NextPart_001_01BF68ED.79D71A82--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:46:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10602
	for ; Thu, 27 Jan 2000 12:46:23 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBFE0D70@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:42:07 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11396 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:40:55 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C0D81000@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:40:55 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:42:11 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 12:41:51
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 11:41:48 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68ED.C7E03240"
Message-ID:  
Date:         Thu, 27 Jan 2000 11:41:47 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: DTMF and Signals descriptor
X-To:         Jo Friedman 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68ED.C7E03240
Content-Type: text/plain

The intention was that the default duration for DTMF be provisioned (or
designed) in the MG.  If we put values into the package as it stands, it
will have to be reworked to operate outside of North America.

> -----Original Message-----
> From: Jo Friedman [SMTP:jo@AZTEK-ENG.COM]
> Sent: Tuesday, January 25, 2000 10:58 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: DTMF and Signals descriptor
>
> Brian,
> You made two statements below that aren't explicitly stated in the spec
> and
> probably would have helped me understand signals better.
>
> "Since the default SignalType for dtmf digits is BRief, the duration is
> fixed (or provisioned) it could be overriden by using the duration
> parameter"
>
> "A normal signal has a default duration ...."
>
> Since signalType and duration are optional  should the default signalType
> and
> duration  values be specified in the package? This is actually stated in
> 12.1.4,
> but the packages in Annex E (e.g., basic DTMF generator) don't define
> these
> default values. I think this is where I got confused.
>
> Jo
>
> "Rosen, Brian" wrote:
>
> > See comments below
> >
> > > -----Original Message-----
> > > From: Jo Friedman [mailto:jo@aztek-eng.com]
> > > Sent: Monday, January 24, 2000 5:42 PM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: DTMF and Signals descriptor
> > >
> > >
> > > Please tell me if I'm correct in assuming that there are at least
> > > two ways for the MGC to request the MG to signal DTMF digits on a
> > > physical termination. I also have some V13 comments related to
> > > the signal descriptor below.
> > >
> > > Are both of these correct for dialing '125'?
> > >
> > > Signals {
> > >    dg/pt {
> > >       ind=100,         ; interdigit duration
> > >       tl=[d1,d2,d5]   ; dtmf digits 125
> > >    }
> > > }
> > > In this case how is the signal duration specified?
> > Since the default SignalType for dtmf digits is BRief, the duration is
> > fixed (or provisioned) it could be overriden by using the duration
> parameter
> >
> > to specify something else.  SignalType and Duration are available for
> every
> > signal.
> >
> > >
> > > or
> > >
> > > SignalList = 10 {
> > >    SignalType=Timeout,
> > >    Duration=250,
> > >    dg/d1,
> > >    dg/d2,
> > >    dg/d5
> > > }
> > Yes
> >
> > > V13 comments:
> > > In 7.1.11 the last sentence of the 1st paragraph refers to
> > > "sequential play lists". I assume that is the same as "sequential
> > > signal lists" so it should be replaced to avoid confusion.
> > Yes, we should fix this
> >
> > >
> > > In the ABNF for signalListParm the preceding comments contains
> > > the phrase "at most once duration and every signal parameter". I
> > > understand "at most once duration" but I don't understand what is
> > > meant to be conveyed by the rest of the phrase.
> > I think it means that a parameter to a signal can only occur once per
> > signal instance in the list (but signal can occur more than once, and
> > in each case signal parameters can be included (once).
> >
> > >
> > > In the ABNF for signalListParm if SigSignalType=Timeout is
> > > sigDuration required? The description of timeout in 7.1.11
> > > implies if there is no duration the signal is played until it is
> > > turned off. In a signal list this doesn't make sense because the
> > > first signal in the list would be the only signal played,
> > > wouldn't it?
> > I don't think we talked about this.  A normal signal has a default
> duration
> > and if not specified, that is what you use.  A signal list does not have
> > a default duration.  At the moment, I'd say it's an error to specify
> > SignalType = TimeOut and not specify Duration.
> >
> > >
> > > Thanks for any clarifications!
> > > Jo
> > >
> >
> > Brian

------_=_NextPart_001_01BF68ED.C7E03240
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: DTMF and Signals descriptor




        The intention was =
that the default duration for DTMF be provisioned (or designed) in the =
MG.  If we put values into the package as it stands, it will have =
to be reworked to operate outside of North America.
        

          

          -----Original Message-----

          From:   Jo Friedman [SMTP:jo@AZTEK-ENG.COM]

          Sent:   Tuesday, January 25, 2000 10:58 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: DTMF and Signals =
descriptor

          


          Brian,

          You made two statements below that =
aren't explicitly stated in the spec and

          probably would have helped me =
understand signals better.

          


          "Since the default SignalType for =
dtmf digits is BRief, the duration is

          fixed (or provisioned) it could be =
overriden by using the duration parameter"

          


          "A normal signal has a default =
duration ...."

          


          Since signalType and duration are =
optional  should the default signalType and

          duration  values be specified in =
the package? This is actually stated in 12.1.4,

          but the packages in Annex E (e.g., =
basic DTMF generator) don't define these

          default values. I think this is where =
I got confused.

          


          Jo

          


          "Rosen, Brian" wrote:

          


          > See comments below

          >

          > > -----Original =
Message-----

          > > From: Jo Friedman =
[mailto:jo@aztek-eng.com<=
FONT SIZE=3D2 FACE=3D"Arial">]          

          > > Sent: Monday, January 24, =
2000 5:42 PM

          > > To: =
MEGACO@standards.nortelnetworks.com

          > > Subject: DTMF and Signals =
descriptor

          > >

          > >

          > > Please tell me if I'm =
correct in assuming that there are at least

          > > two ways for the MGC to =
request the MG to signal DTMF digits on a

          > > physical termination. I =
also have some V13 comments related to

          > > the signal descriptor =
below.

          > >

          > > Are both of these correct =
for dialing '125'?

          > >

          > > Signals {

          > >    dg/pt =
{

          > =
>       =
ind=3D100,         ; interdigit =
duration

          > >     =
;  tl=3D[d1,d2,d5]   ; dtmf digits 125

          > >    }

          > > }

          > > In this case how is the =
signal duration specified?

          > Since the default SignalType for =
dtmf digits is BRief, the duration is

          > fixed (or provisioned) it could =
be overriden by using the duration parameter

          >

          > to specify something else.  =
SignalType and Duration are available for every

          > signal.

          >

          > >

          > > or

          > >

          > > SignalList =3D 10 {

          > >    =
SignalType=3DTimeout,

          > >    =
Duration=3D250,

          > >    =
dg/d1,

          > >    =
dg/d2,

          > >    =
dg/d5

          > > }

          > Yes

          >

          > > V13 comments:

          > > In 7.1.11 the last sentence =
of the 1st paragraph refers to

          > > "sequential play =
lists". I assume that is the same as "sequential

          > > signal lists" so it =
should be replaced to avoid confusion.

          > Yes, we should fix this

          >

          > >

          > > In the ABNF for =
signalListParm the preceding comments contains

          > > the phrase "at most =
once duration and every signal parameter". I

          > > understand "at most =
once duration" but I don't understand what is

          > > meant to be conveyed by the =
rest of the phrase.

          > I think it means that a =
parameter to a signal can only occur once per

          > signal instance in the list (but =
signal can occur more than once, and

          > in each case signal parameters =
can be included (once).

          >

          > >

          > > In the ABNF for =
signalListParm if SigSignalType=3DTimeout is

          > > sigDuration required? The =
description of timeout in 7.1.11

          > > implies if there is no =
duration the signal is played until it is

          > > turned off. In a signal =
list this doesn't make sense because the

          > > first signal in the list =
would be the only signal played,

          > > wouldn't it?

          > I don't think we talked about =
this.  A normal signal has a default duration

          > and if not specified, that is =
what you use.  A signal list does not have

          > a default duration.  At the =
moment, I'd say it's an error to specify

          > SignalType =3D TimeOut and not =
specify Duration.

          >

          > >

          > > Thanks for any =
clarifications!

          > > Jo

          > >

          >

          > Brian

          

        


------_=_NextPart_001_01BF68ED.C7E03240--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:46:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10611
	for ; Thu, 27 Jan 2000 12:46:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EC707E50@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:42:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11403 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:41:05 -0500
Received: from sj-mailhub-2.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.C675BEE0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:41:04
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by
          sj-mailhub-2.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA14091; Thu, 27
          Jan 2000 09:46:02 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id JAA23492; Thu, 27 Jan 2000 09:42:42 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <4FBEA8857476D311A03300204840E1CF208844@whq-msgusr-02.fore.com>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14480.33681.999051.351797@thomasm-u1.cisco.com>
Date:         Thu, 27 Jan 2000 09:42:41 -0800
Reply-To: Michael Thomas 
Sender: "Media Gateway Control (megaco)"
              
From: Michael Thomas 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <4FBEA8857476D311A03300204840E1CF208844@whq-msgusr-02.fore.com>
Content-Transfer-Encoding: 7bit

Rosen, Brian writes:
 > Can't say I have a really good reason, but I think that two ways
 > to do the same thing are a bad idea.

   So it's better to invent an artificial difference
   to give Add some claim to uniqueness which is
   basically covering up that it would otherwise
   just be a subset of Move?

   From a programming standpoint, I'd much rather
   code a Move superset function where Add is
   just an API convenience, rather than have to
   deal with exceptions that are exceptions for
   the sake of being exceptions.

   PS: doesn't Modify also meet this test too?
   Eg, Modify is nothing more than Move to and
   from the same destination context? Should we
   invent a uniqueness barrier here too? Ditto
   Subtract?

            Mike

 >
 > Brian
 >
 > > -----Original Message-----
 > > From: Michael Thomas [mailto:mat@cisco.com]
 > > Sent: Thursday, January 27, 2000 11:45 AM
 > > To: Rosen, Brian
 > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > > Subject: Re: Subtract Command with wildcard Termination Name
 > >
 > >
 > > Rosen, Brian writes:
 > >  > It is legal to move a termination to a new context, but we
 > >  > wanted to not allow that from null context.
 > >
 > >    Why is this? If you allowed it, it seems that
 > >    Add would just be a subset of Move.
 > >
 > >         Mike
 > >  >
 > >  > Brian
 > >  >
 > >  > > -----Original Message-----
 > >  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
 > >  > > Sent: Thursday, January 27, 2000 12:59 AM
 > >  > > To: Rosen, Brian
 > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > Agreed that "Choose in a ContextId is create a new one".
 > >  > > Does this mean that
 > >  > > in MOVE $ in ContextID is allowed (Move a termination to a
 > >  > > "new" context)? Or is
 > >  > > it that
 > >  > > $ in ContextID is only allowed in case of ADD?
 > >  > >
 > >  > > We need to add the following line somewhere in the text:
 > >  > > "A $ in ContextID means to CREATE a new context and except
 > >  > > ADD (and MOVE ??)
 > >  > > it can't appear in any other command"
 > >  > >
 > >  > > Regarding ContextID * and $ in Subtract our thinking was:
 > >  > > 1) ContextID * means "search for a termination in all
 > >  > > contexts and subtract from
 > >  > > it"
 > >  > > 2) ContextId $ means "find the context in which the
 > >  > > termination exists and
 > >  > > subtract it from that context"
 > >  > > By this logical meaning it seems that both are valid. But now
 > >  > > we agree to what
 > >  > > you say and (2) is not allowed.
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
 > >  > >
 > >  > > Please respond to "Rosen, Brian" 
 > >  > >
 > >  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > >
 > >  > > Subject:  Re: Subtract Command with wildcard Termination Name
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > > Just sent a couple of messages that address this:
 > >  > > Choose in a ContextId is create a new one
 > >  > >
 > >  > > Brian
 > >  > >
 > >  > > > -----Original Message-----
 > >  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
 > >  > > > Sent: Tuesday, January 25, 2000 9:38 AM
 > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > > > Subject: Re: Subtract Command with wildcard Termination Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
 > >  > > > that choose
 > >  > > >  the context  in which the given Termination exist and
 > >  > > > subtract the termination.
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
 > >  > > >
 > >  > > > Please respond to "Rosen, Brian" 
 > >  > > >
 > >  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > > cc:    (bcc: Sachin Mittal/HSS)
 > >  > > >
 > >  > > > Subject:  Re: Subtract Command with wildcard Termination Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > I think this is headed in the wrong direction.  Subtract of
 > >  > > wildcarded
 > >  > > > contextId was explicitly allowed for,
 > >  > > > among other things, the response to a ServiceChange with mass
 > >  > > > out of service
 > >  > > > operations pending.
 > >  > > > The MGC must subtract all calls, and do it in a hurry.
 > >  > > >
 > >  > > > It is also useful in a wildcard Audit, with or without W-.
 > >  > > >
 > >  > > > So I think it is allowed, period.
 > >  > > >
 > >  > > > Brian
 > >  > > >
 > >  > > > -----Original Message-----
 > >  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
 > >  > > > Sent: Monday, January 24, 2000 10:06 AM
 > >  > > > To: MEGACO@standards.nortelnetworks.com
 > >  > > > Subject: Re: Subtract Command with wildcard Termiantion Name
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > > > Your question has a couple of wider implications.  My first
 > >  > > > reaction was to
 > >  > > > say this was an error, because in principle the MGC can
 > >  > > > always know which
 > >  > > > context a termination is in, through audits if necessary.
 > >  > > > Then I checked
 > >  > > > out our audit response syntax and realized that the MGC
 > >  > > > cannot determine the
 > >  > > > current context of a termination if it doesn't know it already.
 > >  > > >
 > >  > > > I think the answer has to be that we change the production
 > >  > > > auditOther to
 > >  > > > include the context ID.
 > >  > > >
 > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
 > >  > > ContextID
 > >  > > > terminationAudit RBRKT
 > >  > > >
 > >  > > > Then the answer to your original question is that it
 > > is an error.
 > >  > > >
 > >  > > >         -----Original Message-----
 > >  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
 > >  > > > Sent:   Sunday, January 23, 2000 11:56 PM
 > >  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
 > >  > > > Subject:        Subtract Command with wildcard Termiantion Name
 > >  > > >
 > >  > > >         Hi!
 > >  > > >      Here is a small query regarding the case where ContextID
 > >  > > > is "*" and
 > >  > > > Termination Name is fully-specified. Does this implies that
 > >  > > > MGC intends to
 > >  > > > Subtract the specific termination from
 > >  > > > "whichever" context it appears in ? Or it is an error because
 > >  > > > a termination
 > >  > > > can
 > >  > > > exist only in one context and
 > >  > > > ContextID = "*" for a specific termination is an error ?
 > >  > > >
 > >  > > >         Regards
 > >  > > > MadhuBabu
 > >  > > >
 > >  > > >
 > >  > > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  > >
 > >  >
 > >  >
 > >
 >
 >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:47:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10644
	for ; Thu, 27 Jan 2000 12:47:52 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58DADB80@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:45:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11426 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:43:38 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.22156750@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:43:38 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:44:35 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 12:44:21 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:44:20 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68EE.224822E2"
Message-ID:  
Date:         Thu, 27 Jan 2000 12:44:17 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: BufferedEventHandling
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68EE.224822E2
Content-Type: text/plain

Event handling received a LOT of discussion in Washington.  The existing
text dates from there; I can't see revisiting the issue.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 6:23 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      BufferedEventHandling
>
> Section:        7.1.7
> Category:       Technical, Open Issue
> Issue:          At the end of the Red Bank meeting, Section 7.1.7 on
> LocalControlDescriptor (Section 7.1.8 in TD-58 from the Red Bank meeting
> [3]), contained the following text: "The TerminationBuffered parameter
> describes actions taken by the MG when events are not immediately notified
> to the controller.
> 1.      BufferedEventProcessingMode  specifies whether buffered events
> should be
> processed (Process) or discarded (Discard)
> 2.      BufferedEventNotificationMode  specifies whether the Media Gateway
> is
> expected to detect the requested event and notify the controller once
> (step
> by step) or repeatedly (Loop).
> The white contribution does not contain this text which constitutes a
> significant technical change to the operation of event detection and
> notification which we strongly disagree with.
> Discussion:             It is recommended that the above deleted text is
> added to
> Section 7.1.7 again.
>
> v13 Status:     WIDE OPEN. Text still missing. Extensive modification of
> entire
> event processing has taken place.
>
>
> Section:        7.2.7, second last paragraph
> Category:       Technical, Open Issue
> Issue:          The draft text specifies that "If the
> BufferedEventProcessingMode
> parameter of the Termination is set to "Discard", then the list shall
> contain only the event that triggered the notification".
> This constitutes a significant technical change to the operation of event
> detection as indicated earlier for Section 7.1.7. The text was not present
> at the end of the Red Bank meeting [3], nor should it be. Furthermore, the
> text does not seem to make much sense; if an event is not to be reported,
> then it is simply not included in the EventsDescriptor. This relates to
> the
> removal of the BufferedEventNotificationMode which should not have
> happened.
> Discussion:     It is strongly recommended that the specification on event
> buffering concerning both notification and processing is revisited and
> brought back in line with the outcome of the Red Bank meeting.
>
> v13 Status:     OPEN. Although the text has been removed, it is part of an
> extensive modification of the entire event handling mechanism.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF68EE.224822E2
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: BufferedEventHandling




        Event handling =
received a LOT of discussion in Washington.  The existing text =
dates from there; I can't see revisiting the issue.
        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

          Sent:   Tuesday, January 25, 2000 6:23 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 BufferedEventHandling

          


          Section:        =
7.1.7

          Category:       Technical, =
Open Issue

          Issue:        &nb=
sp; At the end of the Red Bank meeting, Section 7.1.7 on

          LocalControlDescriptor (Section 7.1.8 =
in TD-58 from the Red Bank meeting

          [3]), contained the following text: =
"The TerminationBuffered parameter

          describes actions taken by the MG =
when events are not immediately notified

          to the controller.

          1.      =
BufferedEventProcessingMode  specifies whether buffered events =
should be

          processed (Process) or discarded =
(Discard)

          2.      =
BufferedEventNotificationMode  specifies whether the Media Gateway =
is

          expected to detect the requested =
event and notify the controller once (step

          by step) or repeatedly (Loop).

          The white contribution does not =
contain this text which constitutes a

          significant technical change to the =
operation of event detection and

          notification which we strongly =
disagree with.

          Discussion:       &nbs=
p;     It is recommended that the above deleted =
text is added to

          Section 7.1.7 again.

          


          v13 Status:     =
WIDE OPEN. Text still missing. Extensive modification of entire

          event processing has taken =
place.

          

          


          Section:        =
7.2.7, second last paragraph

          Category:       Technical, =
Open Issue

          Issue:        &nb=
sp; The draft text specifies that "If the =
BufferedEventProcessingMode

          parameter of the Termination is set =
to "Discard", then the list shall

          contain only the event that triggered =
the notification".

          This constitutes a significant =
technical change to the operation of event

          detection as indicated earlier for =
Section 7.1.7. The text was not present

          at the end of the Red Bank meeting =
[3], nor should it be. Furthermore, the

          text does not seem to make much =
sense; if an event is not to be reported,

          then it is simply not included in the =
EventsDescriptor. This relates to the

          removal of the =
BufferedEventNotificationMode which should not have happened.

          Discussion:     =
It is strongly recommended that the specification on event

          buffering concerning both =
notification and processing is revisited and

          brought back in line with the outcome =
of the Red Bank meeting.

          


          v13 Status:     =
OPEN. Although the text has been removed, it is part of an

          extensive modification of the entire =
event handling mechanism.

          

          


          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF68EE.224822E2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 12:56:30 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10773
	for ; Thu, 27 Jan 2000 12:56:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C656540@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:54:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:53:12 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7804CDD0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:53:12 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:54:29 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 12:54:16
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 11:54:13 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68EF.84A0FD1E"
Message-ID:  
Date:         Thu, 27 Jan 2000 11:54:09 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Optional descriptors
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68EF.84A0FD1E
Content-Type: text/plain

What would the MGC do with the information if you did provide it?  It's not
a programmer, so it wouldn't know how to adjust.

I think the real solution in the spirit of our protocol is to define the
properties which can go into these descriptors in packages.  That way the
granularity of the MG's response is finer -- it may support some muxes but
not others, for instance.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Thursday, January 27, 2000 10:14 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Optional descriptors
>
> In case an MG doesn't support multimedia calls, it may not implement
> Multiplex
> Descriptor.
> If this is also true for say Modem Descriptor and in a command both these
> descriptors
> together with other supported descriptor(s) goes to MG. Although it is
> true that
> the command will
> fail but there is no way of informing MGC which descriptors are
> unsupported
> "error code - 444"
> (Descriptors can be returned only when any value is modified)
>
> Shouldn't we modify the Base ROOT package to support this. Is it that only
> toplogy descriptor
> is optional?

------_=_NextPart_001_01BF68EF.84A0FD1E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Optional descriptors




        What would the MGC =
do with the information if you did provide it?  It's not a =
programmer, so it wouldn't know how to adjust.
        


        I think the real =
solution in the spirit of our protocol is to define the properties =
which can go into these descriptors in packages.  That way the =
granularity of the MG's response is finer -- it may support some muxes =
but not others, for instance.
        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Thursday, January 27, 2000 10:14 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Optional descriptors

          


          In case an MG doesn't support =
multimedia calls, it may not implement Multiplex

          Descriptor.

          If this is also true for say Modem =
Descriptor and in a command both these

          descriptors

          together with other supported =
descriptor(s) goes to MG. Although it is true that

          the command will

          fail but there is no way of informing =
MGC which descriptors are unsupported

          "error code - 444"

          (Descriptors can be returned only =
when any value is modified)

          


          Shouldn't we modify the Base ROOT =
package to support this. Is it that only

          toplogy descriptor

          is optional?

          

        


------_=_NextPart_001_01BF68EF.84A0FD1E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:02:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10996
	for ; Thu, 27 Jan 2000 13:02:31 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73E05C00@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:00:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11487 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 12:58:58 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.46855620@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          12:58:58 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 11:59:39 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 12:59:06 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:59:06 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Thu, 27 Jan 2000 12:59:05 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Re: Choosing of ephemeral / physical Termination
X-cc:         Brian Rosen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Second try -- doesn't seem to have shown up before.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Wednesday, January 26, 2000 6:59 PM
> To:   'Megaco'
> Subject:      Re: Choosing of ephemeral / physical Termination
>
> There are two answers to Brian's example  Context=${Add=${}}
>
> First answer: the MG allocates a terminationID and (depending on
> implementation) any software resources required to hold further
> information about the termination.  It has no other information for the
> moment, and will return an error if there is any attempt to activate a
> flow on the termination without supplying that information.
>
> Second answer: the MG will reject any Add request which does not provide
> the information needed to determine the underlying bearer type of the
> termination.  The necessary information is provided either by providing
> the nettype within a Local or Remote session description, or by naming a
> provisioned termination (possibly with wildcarding, but narrowing the
> selection to terminations all having the same nettype).
>
> I think the first answer is reasonable, but let's hear what other people
> have to say.  In any event, the answer to Sachin's question is that the
> kind of termination is determined from the Media descriptor or from the
> name, as I've suggested above.
>
>
>                     Date:         Wed, 26 Jan 2000 16:06:46 -0500
>                     Reply-To:     "Rosen, Brian" 
>                     Sender:       "Media Gateway Control (megaco)"
>                                   
>                     From:         "Rosen, Brian" 
>                     Subject:      Re: Choosing of ephemeral / physical
> Termination.
>                     X-To:         "samittal@hss.hns.com"
> 
>                     Content-Type: text/plain; charset="iso-8859-1"
>
>                     Generally determined by the "kind" of termination
> requested.
>                     Which is in turn, easily discernable from the Media
> command.
>
>                     However, upon reflection, I think it's not a good
> answer.
>                     I'd propose that we not allow selection of a physical
> termination,
>                     in which case choose is always create an ephemeral.
> In particular,
>                     the following is perfectly legal:
>                     Context=${Add=${}}
>                     What do you get?
>
>                     Brian
>
>                     > -----Original Message-----
>                     > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>                     > Sent: Tuesday, January 25, 2000 9:01 AM
>                     > To: MEGACO@standards.nortelnetworks.com
>                     > Subject: Choosing of ephemeral / physical
> Termination.
>                     >
>                     >
>                     > Annex B.1 says that "The CHOOSE TerminationID $ may
> be used
>                     > to signal to the MG
>                     > that it has to create an
>                     > ephemeral Termination or select an idle physical
> Termination".
>                     > How can MG determine when to create an ephemeral
> termination
>                     > and when to choose
>                     > idle physical termination.??
>                     > What is the logic behind this decision making?
>                     >
>                     > regards
>                     > -Sachin Mittal
>                     >
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:07:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11104
	for ; Thu, 27 Jan 2000 13:07:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2797E5B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:05:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11472 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:04:39 -0500
Received: from gconsrv02.g-connect.co.il by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.ABDD8250@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:54:39
          -0500
Received: by GCONSRV02 with Internet Mail Service (5.5.2650.21) id ;
          Thu, 27 Jan 2000 19:55:44 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68EF.BBBBC702"
Message-ID:  
Date:         Thu, 27 Jan 2000 19:55:44 +0200
Reply-To: Yair Arian 
Sender: "Media Gateway Control (megaco)"
              
From: Yair Arian 
Subject:      NAS and Calling/Called Numbers.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68EF.BBBBC702
Content-Type: text/plain;
        charset="WINDOWS-1255"

Hi,
  When the MG is a NAS and the Calling/Called numbers arrive at the MGC via
the Signaling Network (SS7), how does
the MGC convey these numbers to the NAS?  These numbers are needed for
authentication performed via the RADIUS by
the NAS and for other purposes.
Yair Arian.
G-Connect Ltd.

------_=_NextPart_001_01BF68EF.BBBBC702
Content-Type: text/html;
        charset="WINDOWS-1255"
Content-Transfer-Encoding: quoted-printable






NAS and Calling/Called Numbers.




        Hi,

          When the MG is a NAS and the =
Calling/Called numbers arrive at the MGC via the Signaling Network =
(SS7), how does

        the MGC convey these numbers to the =
NAS?  These numbers are needed for authentication performed via =
the RADIUS by

        the NAS and for other =
purposes.

        Yair Arian.

        G-Connect Ltd.

        



------_=_NextPart_001_01BF68EF.BBBBC702--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:13:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11237
	for ; Thu, 27 Jan 2000 13:13:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB1D89F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:10:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11486 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:08:31 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.35FFC0B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 12:58:30
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA10548; Thu, 27 Jan
          2000 13:00:06 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA00611; Thu, 27 Jan
          2000 13:00:08 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 12:57:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68EF.EB509524"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208846@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 13:00:05 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Auditing Of Packages
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68EF.EB509524
Content-Type: text/plain;
        charset="iso-8859-1"

This might be theoretically true, but in fact you have to implement dtmf
detect before you
can use digitmaps, because they only operate on dtmf digits,

If we had gone ahead and generalized the mechanism to work on arbitrary
sequences
of detectable events, then what you suggest would make sense.  As they are
now
defined, they are limited to MGs that implement dtmf detect.  That being
said, we get to
the IPPhone folks' definition of optional. If I keep the same stance I took
with them
you have to implement the DigitMap descriptor even if you don't implement
dtmf detect.
You have to accept a digitmap in an event even if you don't implement dtmf
detect, and
auditing of same has to work.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, January 27, 2000 12:36 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Auditing Of Packages



Terminations in themselves are media-independent.  Hence in principle they
should all support digit maps.  The events which get mapped into digit maps
may be associated with specific media, as indicated by the relevant
packages.

        -----Original Message-----
From:   Chip Sharp [SMTP:chsharp@cisco.com]
Sent:   Thursday, January 27, 2000 11:07 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: Auditing Of Packages

        At 09:23 PM 1/26/00 -0500, Tom-PT Taylor wrote:
>Every termination should support digit map capability, so digit map names
   ^^^^^^^^^^^^^^^^^^^^^
I assume this was a typo?  Do you really mean that every termination (e.g.,
a video termination) should support digit maps?

        >and values are all you would want to audit.  AuditValue is logical
for that.
>This leaves packages, which happen to be tied into what types of ephemeral
>termination an MG will support.  Doctrine coming out of Washington was that

>you would find out the latter by digging out the termination naming
pattern,
>then walking through  the naming tree to determine the capabilities
>supported by each branch.  As Chip points out immediately below, however,
>you cannot currently determine the packages supported by a termination
until
>it has been instantiated.  It seems reasonable that AuditCapability also
>return a PackageList, the packages potentially supported by the termination

>as opposed to those actually invoked.
>
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>
>                     Section:        7.2.6, last line
>                     Category:       Technical
>                     Issue:          The draft text specifies that
"DigitMap
>and Packages are
>                     not legal in AuditCapability". This is inconsistent
with
>the return
>                     parameters shown for the example API. Furthermore, it
>would seem reasonable
>                     to be able determine what packages a termination (or
>gateway) supports as
>                     well as whether digit map is supported or not.
Although
>packages can be
>                     audited with AuditValue, it would seem to make more
>sense to allow it in
>                     AuditCapability.
>                     Proposal:       It is proposed to strike the above
>sentence and allow for
>                     auditing of these two capabilities.
>
>                     v13 Status:     OPEN. No relevant text changed.
>
>                     Section:        7.2.6
>                     Category:       Open Issue
>                     Issue:          The current draft text does not
specify
>how to audit
>                     ephemerals at startup. This issue was identified by
the
>IETF editor but has
>                     not yet been resolved (issue 1). The issue is, that
when
>you boot and have
>                     not yet created any ephemeral terminations, how do you

>know what the MG can
>                     do. For example, how do you know if the MG has say an
IP
>interface, and ATM
>                     interface, an MPLS interface or a Frame Relay
interface
>. If you could
>                     audit something, you could look at the "network" value

>in LocalControl.
>                     Discussion:             A continuation of the
discussion
>that has occurred
>                     on the Megaco mailing list so far is needed in order
to
>resolve the issue.
>
>                     v13 Status:     OPEN. No relevant text has been added.

>
>Tom Taylor
>Advisor -- IPConnect Standards
>E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961

        Support NetAid!  http://www.netaid.org 
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


------_=_NextPart_001_01BF68EF.EB509524
Content-Type: text/html;
        charset="iso-8859-1"




RE: Auditing Of Packages




        This
might be theoretically true, but in fact you have to implement dtmf detect
before you
        

        can
use digitmaps, because they only operate on dtmf digits,
        

         
        

        If we
had gone ahead and generalized the mechanism to work on arbitrary
sequences
        

        of
detectable events, then what you suggest would make sense.  As they are now

        

        defined, they are limited to MGs that implement dtmf
detect.  That being said, we get to
        

        the
IPPhone folks' definition of optional. If I keep the same stance I took with
them
        

        you
have to implement the DigitMap descriptor even if you don't implement dtmf
detect.
        

        You
have to accept a digitmap in an event even if you don't implement dtmf detect,
and
        

        auditing of same has to work.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Thursday, January 27, 2000
  12:36 PM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Auditing Of Packages

        
  
        Terminations in themselves are
  media-independent.  Hence in principle they should all support digit
  maps.  The events which get mapped into digit maps may be associated with
  specific media, as indicated by the relevant packages.
        
  
          
    
          -----Original Message----- 
          From:   Chip
    Sharp [SMTP:chsharp@cisco.com] 
          Sent:   Thursday,
    January 27, 2000 11:07 AM 
          To:     Taylor, Tom-PT [CAR:B904:EXCH];
    MEGACO@STANDARDS.NORTELNETWORKS.COM 
          Subject:        Re: Auditing Of Packages 
          
    
          At 09:23 PM 1/26/00 -0500, Tom-PT Taylor
    wrote: 
          >Every termination should
    support digit map capability, so digit map names 
             ^^^^^^^^^^^^^^^^^^^^^ 
          I assume this was a typo?  Do you really mean that every
    termination (e.g., 
          a video termination)
    should support digit maps? 
          
    
          >and values are all you would want to
    audit.  AuditValue is logical for that. 
          >This leaves packages, which happen to be tied into what types of
    ephemeral 
          >termination an MG will
    support.  Doctrine coming out of Washington was that 
          >you would find out the latter by digging out the
    termination naming pattern, 
          >then
    walking through  the naming tree to determine the capabilities
    
          >supported by each branch.  As Chip
    points out immediately below, however, 
          >you cannot currently determine the packages supported by a
    termination until 
          >it has been
    instantiated.  It seems reasonable that AuditCapability also
    
          >return a PackageList, the packages
    potentially supported by the termination 
          >as opposed to those actually invoked. 
          > 
          > 
          >                    
    From:         Chip Sharp
    <chsharp@CISCO.COM> 
          >                    
    Subject:      Auditing 
          > 
          >                    
    Section:        7.2.6, last line
    
          >                    
    Category:       Technical 
          >                    
    Issue:          The draft text
    specifies that "DigitMap 
          >and Packages
    are 
          >                    
    not legal in AuditCapability". This is inconsistent with 
          >the return 
          >                    
    parameters shown for the example API. Furthermore, it 
          >would seem reasonable 
          >                    
    to be able determine what packages a termination (or 
          >gateway) supports as 
          >                    
    well as whether digit map is supported or not. Although 
          >packages can be 
          >                    
    audited with AuditValue, it would seem to make more 
          >sense to allow it in 
          >                    
    AuditCapability. 
          >                    
    Proposal:       It is proposed to strike the
    above 
          >sentence and allow for
    
          >                    
    auditing of these two capabilities. 
          > 
          >                    
    v13 Status:     OPEN. No relevant text changed.
    
          > 
          >                    
    Section:        7.2.6 
          >                    
    Category:       Open Issue 
          >                    
    Issue:          The current
    draft text does not specify 
          >how to
    audit 
          >                    
    ephemerals at startup. This issue was identified by the 
          >IETF editor but has 
          >                    
    not yet been resolved (issue 1). The issue is, that when 
          >you boot and have 
          >                    
    not yet created any ephemeral terminations, how do you 
          >know what the MG can 
          >                    
    do. For example, how do you know if the MG has say an IP 
          >interface, and ATM 
          >                    
    interface, an MPLS interface or a Frame Relay interface 
          >. If you could 
          >                    
    audit something, you could look at the "network" value 
          >in LocalControl. 
          >                    
    Discussion:            
    A continuation of the discussion 
          >that
    has occurred 
          >                    
    on the Megaco mailing list so far is needed in order to 
          >resolve the issue. 
          > 
          >                    
    v13 Status:     OPEN. No relevant text has been
    added. 
          > 
          >Tom Taylor 
          >Advisor --
    IPConnect Standards 
          >E-mail:
    taylor@nortelnetworks.com (internally, Tom-PT Taylor) 
          >Phone and FAX: +1 613 736 0961 
          
    
          Support NetAid!  http://www.netaid.org 
          -------------------------------------------------- 
          Chip
    Sharp                
    Consulting Engineering 
          Cisco
    Systems             
    Telco Bio-region 
          Reality - Love it or
    Leave it.         
            
          --------------------------------------------------

        

------_=_NextPart_001_01BF68EF.EB509524--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:13:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11240
	for ; Thu, 27 Jan 2000 13:13:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DBA7C890@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:10:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11526 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:09:57 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.CF047660@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          13:09:57 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 12:10:52 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 13:10:44
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:10:41 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68F1.D2042FC0"
Message-ID:  
Date:         Thu, 27 Jan 2000 12:10:41 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Auditing Of Packages
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68F1.D2042FC0
Content-Type: text/plain;
        charset="iso-8859-1"

Read the current wording of digit maps.  Any event package that maps events
to the digits 0-9 and letters A-K can be used with digit maps.  By the way,
the DTMF package does not currently show this mapping, and that has to be
fixed.  The ABNF for digit maps shows MF symbols, and those have to be
deleted.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Thursday, January 27, 2000 1:00 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Auditing Of Packages
>
> This might be theoretically true, but in fact you have to implement dtmf
> detect before you
> can use digitmaps, because they only operate on dtmf digits,
>
> If we had gone ahead and generalized the mechanism to work on arbitrary
> sequences
> of detectable events, then what you suggest would make sense.  As they are
> now
> defined, they are limited to MGs that implement dtmf detect.  That being
> said, we get to
> the IPPhone folks' definition of optional. If I keep the same stance I
> took with them
> you have to implement the DigitMap descriptor even if you don't implement
> dtmf detect.
> You have to accept a digitmap in an event even if you don't implement dtmf
> detect, and
> auditing of same has to work.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Thursday, January 27, 2000 12:36 PM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Auditing Of Packages
>
>
>
>       Terminations in themselves are media-independent.  Hence in
> principle they should all support digit maps.  The events which get mapped
> into digit maps may be associated with specific media, as indicated by the
> relevant packages.
>
>               -----Original Message-----
>       From:   Chip Sharp [SMTP:chsharp@cisco.com]
>       Sent:   Thursday, January 27, 2000 11:07 AM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Re: Auditing Of Packages
>
>               At 09:23 PM 1/26/00 -0500, Tom-PT Taylor wrote:
>       >Every termination should support digit map capability, so digit map
> names
>          ^^^^^^^^^^^^^^^^^^^^^
>       I assume this was a typo?  Do you really mean that every termination
> (e.g.,
>       a video termination) should support digit maps?
>
>               >and values are all you would want to audit.  AuditValue is
> logical for that.
>       >This leaves packages, which happen to be tied into what types of
> ephemeral
>       >termination an MG will support.  Doctrine coming out of Washington
> was that
>       >you would find out the latter by digging out the termination naming
> pattern,
>       >then walking through  the naming tree to determine the capabilities
>
>       >supported by each branch.  As Chip points out immediately below,
> however,
>       >you cannot currently determine the packages supported by a
> termination until
>       >it has been instantiated.  It seems reasonable that AuditCapability
> also
>       >return a PackageList, the packages potentially supported by the
> termination
>       >as opposed to those actually invoked.
>       >
>       >
>       >                     From:         Chip Sharp 
>       >                     Subject:      Auditing
>       >
>       >                     Section:        7.2.6, last line
>       >                     Category:       Technical
>       >                     Issue:          The draft text specifies that
> "DigitMap
>       >and Packages are
>       >                     not legal in AuditCapability". This is
> inconsistent with
>       >the return
>       >                     parameters shown for the example API.
> Furthermore, it
>       >would seem reasonable
>       >                     to be able determine what packages a
> termination (or
>       >gateway) supports as
>       >                     well as whether digit map is supported or not.
> Although
>       >packages can be
>       >                     audited with AuditValue, it would seem to make
> more
>       >sense to allow it in
>       >                     AuditCapability.
>       >                     Proposal:       It is proposed to strike the
> above
>       >sentence and allow for
>       >                     auditing of these two capabilities.
>       >
>       >                     v13 Status:     OPEN. No relevant text
> changed.
>       >
>       >                     Section:        7.2.6
>       >                     Category:       Open Issue
>       >                     Issue:          The current draft text does
> not specify
>       >how to audit
>       >                     ephemerals at startup. This issue was
> identified by the
>       >IETF editor but has
>       >                     not yet been resolved (issue 1). The issue is,
> that when
>       >you boot and have
>       >                     not yet created any ephemeral terminations,
> how do you
>       >know what the MG can
>       >                     do. For example, how do you know if the MG has
> say an IP
>       >interface, and ATM
>       >                     interface, an MPLS interface or a Frame Relay
> interface
>       >. If you could
>       >                     audit something, you could look at the
> "network" value
>       >in LocalControl.
>       >                     Discussion:             A continuation of the
> discussion
>       >that has occurred
>       >                     on the Megaco mailing list so far is needed in
> order to
>       >resolve the issue.
>       >
>       >                     v13 Status:     OPEN. No relevant text has
> been added.
>       >
>       >Tom Taylor
>       >Advisor -- IPConnect Standards
>       >E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>       >Phone and FAX: +1 613 736 0961
>
>               Support NetAid!  
>       --------------------------------------------------
>       Chip Sharp                 Consulting Engineering
>       Cisco Systems              Telco Bio-region
>       Reality - Love it or Leave it.
>       --------------------------------------------------
>

------_=_NextPart_001_01BF68F1.D2042FC0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Auditing Of Packages




        Read the current =
wording of digit maps.  Any event package that maps events to the =
digits 0-9 and letters A-K can be used with digit maps.  By the =
way, the DTMF package does not currently show this mapping, and that =
has to be fixed.  The ABNF for digit maps shows MF symbols, and =
those have to be deleted.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Thursday, January 27, 2000 1:00 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Auditing Of Packages

          


          This might be =
theoretically true, but in fact you have to implement dtmf detect =
before you

          can use digitmaps, =
because they only operate on dtmf digits,

          =A0

          If we had gone =
ahead and generalized the mechanism to work on arbitrary =
sequences

          of detectable =
events, then what you suggest would make sense.=A0 As they are =
now=20

          defined, they are =
limited to MGs that implement dtmf detect.=A0 That being said, we get =
to

          the IPPhone folks' =
definition of optional. If I keep the same stance I took with =
them

          you have to =
implement the DigitMap descriptor even if you don't implement dtmf =
detect.

          You have to accept =
a digitmap in an event even if you don't implement dtmf detect, =
and

          auditing of same =
has to work.

          =A0

          Brian

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Thursday, January 27, 2000 12:36 PM
            
            To: MEGACO@standards.nortelnetworks.com
            
            Subject: Re: Auditing Of Packages
            

            
            

            


            Terminations in =
themselves are media-independent.=A0 Hence in principle they should all =
support digit maps.=A0 The events which get mapped into digit maps may =
be associated with specific media, as indicated by the relevant =
packages.
            


                    -----Original Message-----
            
            From:=A0=A0 Chip Sharp =
[SMTP:chsharp@cisco.com]
            
            Sent:=A0=A0 Thursday, January =
27, 2000 11:07 AM
            
            To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 Re: Auditing Of =
Packages 

            


                    At 09:23 PM 1/26/00 -0500, Tom-PT Taylor =
wrote:
            
            >Every termination should =
support digit map capability, so digit map names
            
            =A0=A0 =
^^^^^^^^^^^^^^^^^^^^^
            
            I assume this was a typo?=A0 Do =
you really mean that every termination (e.g.,
            
a video termination) should support digit =
maps? 

            


                    >and values are all you would want to audit.=A0 =
AuditValue is logical for that.
            
            >This leaves packages, which =
happen to be tied into what types of ephemeral
            
            >termination an MG will =
support.=A0 Doctrine coming out of Washington was that
            
            >you would find out the latter =
by digging out the termination naming pattern,
            
            >then walking through=A0 the =
naming tree to determine the capabilities
            
            >supported by each branch.=A0 =
As Chip points out immediately below, however,
            
            >you cannot currently determine =
the packages supported by a termination until
            
            >it has been instantiated.=A0 =
It seems reasonable that AuditCapability also
            
            >return a PackageList, the =
packages potentially supported by the termination
            
            >as opposed to those actually =
invoked.
            
            >
            
            >
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 From:=A0=A0=A0=A0=A0=A0=A0=A0 Chip Sharp =
<chsharp@CISCO.COM>
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Subject:=A0=A0=A0=A0=A0 Auditing
            
            >
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6, last line
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Technical
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The draft text specifies that =
"DigitMap
            
            >and Packages are
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not legal in AuditCapability". This is inconsistent =
with
            
            >the return
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 parameters shown for the example API. Furthermore, =
it
            
            >would seem =
reasonable
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 to be able determine what packages a termination (or
            
            >gateway) supports =
as
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 well as whether digit map is supported or not. =
Although
            
            >packages can be
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audited with AuditValue, it would seem to make more
            
            >sense to allow it =
in
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 AuditCapability.
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Proposal:=A0=A0=A0=A0=A0=A0 It is proposed to strike the =
above
            
            >sentence and allow =
for
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 auditing of these two capabilities.
            
            >
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text =
changed.
            
            >
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Open Issue
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The current draft text does =
not specify
            
            >how to audit
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 ephemerals at startup. This issue was identified by =
the
            
            >IETF editor but =
has
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet been resolved (issue 1). The issue is, that =
when
            
            >you boot and have
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet created any ephemeral terminations, how do =
you
            
            >know what the MG =
can
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 do. For example, how do you know if the MG has say an =
IP
            
            >interface, and ATM
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 interface, an MPLS interface or a Frame Relay =
interface
            
            >. If you could
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audit something, you could look at the "network" =
value
            
            >in LocalControl.
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Discussion:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A continuation =
of the discussion
            
            >that has occurred
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 on the Megaco mailing list so far is needed in order =
to
            
            >resolve the issue.
            
            >
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text has been =
added.
            
            >
            
            >Tom Taylor
            
            >Advisor -- IPConnect =
Standards
            
            >E-mail: =
taylor@nortelnetworks.com (internally, Tom-PT Taylor)
            
            >Phone and FAX: +1 613 736 =
0961 

            


                    Support NetAid!=A0 <http://www.netaid.org>
            
            --------------------------------------------------=

            
            Chip =
Sharp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Consulting =
Engineering
            
            Cisco =
Systems=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Telco =
Bio-region
            
            Reality - Love it or Leave it.=A0 =
=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0
            
--------------------------------------------------=
 

            

        


------_=_NextPart_001_01BF68F1.D2042FC0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:22:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11400
	for ; Thu, 27 Jan 2000 13:22:50 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.432C86D0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:20:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11523 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:18:41 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.A1C16550@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:08:41
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA12252; Thu, 27 Jan
          2000 13:10:27 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA03162; Thu, 27 Jan
          2000 13:10:30 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 13:07:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208847@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 13:10:27 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I always thought of the commands as actually working that way,
and it's how I would implement them, dd/Move/Modify is one command with some
syntactic sugar that makes the intention clearer.

You will note that the ABNF reflects this: we have
AMMRequest and AMMReply instead of separate constructs for
each command.

I've also pointed out that AuditValue is actually a no-op command
(since Audit can occur in AMM & Subtract), and Subtract is
        Context=-{Move={Audit{Statistics}}}

We do state that Move of the last termination causes the context
to be deleted (as well as Subtract of the last termination).
Making Move to Null have the side effect of deleting an ephemeral has the
same sort of rule.

In the IETF tradition, we could make the text say that the sender shall not
do this kind of thing, and the receiver shall
accept this kind of thing.

Brian


> -----Original Message-----
> From: Michael Thomas [mailto:mat@cisco.com]
> Sent: Thursday, January 27, 2000 12:43 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Subtract Command with wildcard Termination Name
>
>
> Rosen, Brian writes:
>  > Can't say I have a really good reason, but I think that two ways
>  > to do the same thing are a bad idea.
>
>    So it's better to invent an artificial difference
>    to give Add some claim to uniqueness which is
>    basically covering up that it would otherwise
>    just be a subset of Move?
>
>    From a programming standpoint, I'd much rather
>    code a Move superset function where Add is
>    just an API convenience, rather than have to
>    deal with exceptions that are exceptions for
>    the sake of being exceptions.
>
>    PS: doesn't Modify also meet this test too?
>    Eg, Modify is nothing more than Move to and
>    from the same destination context? Should we
>    invent a uniqueness barrier here too? Ditto
>    Subtract?
>
>           Mike
>
>  >
>  > Brian
>  >
>  > > -----Original Message-----
>  > > From: Michael Thomas [mailto:mat@cisco.com]
>  > > Sent: Thursday, January 27, 2000 11:45 AM
>  > > To: Rosen, Brian
>  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > > Rosen, Brian writes:
>  > >  > It is legal to move a termination to a new context, but we
>  > >  > wanted to not allow that from null context.
>  > >
>  > >    Why is this? If you allowed it, it seems that
>  > >    Add would just be a subset of Move.
>  > >
>  > >         Mike
>  > >  >
>  > >  > Brian
>  > >  >
>  > >  > > -----Original Message-----
>  > >  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
>  > >  > > Sent: Thursday, January 27, 2000 12:59 AM
>  > >  > > To: Rosen, Brian
>  > >  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > Agreed that "Choose in a ContextId is create a new one".
>  > >  > > Does this mean that
>  > >  > > in MOVE $ in ContextID is allowed (Move a termination to a
>  > >  > > "new" context)? Or is
>  > >  > > it that
>  > >  > > $ in ContextID is only allowed in case of ADD?
>  > >  > >
>  > >  > > We need to add the following line somewhere in the text:
>  > >  > > "A $ in ContextID means to CREATE a new context and except
>  > >  > > ADD (and MOVE ??)
>  > >  > > it can't appear in any other command"
>  > >  > >
>  > >  > > Regarding ContextID * and $ in Subtract our thinking was:
>  > >  > > 1) ContextID * means "search for a termination in all
>  > >  > > contexts and subtract from
>  > >  > > it"
>  > >  > > 2) ContextId $ means "find the context in which the
>  > >  > > termination exists and
>  > >  > > subtract it from that context"
>  > >  > > By this logical meaning it seems that both are
> valid. But now
>  > >  > > we agree to what
>  > >  > > you say and (2) is not allowed.
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
>  > >  > >
>  > >  > > Please respond to "Rosen, Brian" 
>  > >  > >
>  > >  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > cc:    (bcc: Sachin Mittal/HSS)
>  > >  > >
>  > >  > > Subject:  Re: Subtract Command with wildcard
> Termination Name
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > > Just sent a couple of messages that address this:
>  > >  > > Choose in a ContextId is create a new one
>  > >  > >
>  > >  > > Brian
>  > >  > >
>  > >  > > > -----Original Message-----
>  > >  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>  > >  > > > Sent: Tuesday, January 25, 2000 9:38 AM
>  > >  > > > To: MEGACO@standards.nortelnetworks.com
>  > >  > > > Subject: Re: Subtract Command with wildcard
> Termination Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC
> indicating MG
>  > >  > > > that choose
>  > >  > > >  the context  in which the given Termination exist and
>  > >  > > > subtract the termination.
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>  > >  > > >
>  > >  > > > Please respond to "Rosen, Brian" 
>  > >  > > >
>  > >  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > > cc:    (bcc: Sachin Mittal/HSS)
>  > >  > > >
>  > >  > > > Subject:  Re: Subtract Command with wildcard
> Termination Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > I think this is headed in the wrong direction.
> Subtract of
>  > >  > > wildcarded
>  > >  > > > contextId was explicitly allowed for,
>  > >  > > > among other things, the response to a
> ServiceChange with mass
>  > >  > > > out of service
>  > >  > > > operations pending.
>  > >  > > > The MGC must subtract all calls, and do it in a hurry.
>  > >  > > >
>  > >  > > > It is also useful in a wildcard Audit, with or without W-.
>  > >  > > >
>  > >  > > > So I think it is allowed, period.
>  > >  > > >
>  > >  > > > Brian
>  > >  > > >
>  > >  > > > -----Original Message-----
>  > >  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>  > >  > > > Sent: Monday, January 24, 2000 10:06 AM
>  > >  > > > To: MEGACO@standards.nortelnetworks.com
>  > >  > > > Subject: Re: Subtract Command with wildcard
> Termiantion Name
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > > > Your question has a couple of wider implications.
>  My first
>  > >  > > > reaction was to
>  > >  > > > say this was an error, because in principle the MGC can
>  > >  > > > always know which
>  > >  > > > context a termination is in, through audits if necessary.
>  > >  > > > Then I checked
>  > >  > > > out our audit response syntax and realized that the MGC
>  > >  > > > cannot determine the
>  > >  > > > current context of a termination if it doesn't
> know it already.
>  > >  > > >
>  > >  > > > I think the answer has to be that we change the production
>  > >  > > > auditOther to
>  > >  > > > include the context ID.
>  > >  > > >
>  > >  > > > e.g. auditOther = EQUAL TerminationID LBRKT
> CtxToken EQUAL
>  > >  > > ContextID
>  > >  > > > terminationAudit RBRKT
>  > >  > > >
>  > >  > > > Then the answer to your original question is that it
>  > > is an error.
>  > >  > > >
>  > >  > > >         -----Original Message-----
>  > >  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>  > >  > > > Sent:   Sunday, January 23, 2000 11:56 PM
>  > >  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > >  > > > Subject:        Subtract Command with wildcard
> Termiantion Name
>  > >  > > >
>  > >  > > >         Hi!
>  > >  > > >      Here is a small query regarding the case
> where ContextID
>  > >  > > > is "*" and
>  > >  > > > Termination Name is fully-specified. Does this
> implies that
>  > >  > > > MGC intends to
>  > >  > > > Subtract the specific termination from
>  > >  > > > "whichever" context it appears in ? Or it is an
> error because
>  > >  > > > a termination
>  > >  > > > can
>  > >  > > > exist only in one context and
>  > >  > > > ContextID = "*" for a specific termination is an error ?
>  > >  > > >
>  > >  > > >         Regards
>  > >  > > > MadhuBabu
>  > >  > > >
>  > >  > > >
>  > >  > > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  > >
>  > >  >
>  > >  >
>  > >
>  >
>  >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:25:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11442
	for ; Thu, 27 Jan 2000 13:25:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B3D5170@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:22:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11537 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:21:27 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.01E53650@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:11:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA12510; Thu, 27 Jan
          2000 13:13:00 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA03770; Thu, 27 Jan
          2000 13:13:03 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 13:09:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68F1.B92F822E"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208848@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 13:13:00 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Auditing Of Packages
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68F1.B92F822E
Content-Type: text/plain;
        charset="iso-8859-1"

You are arguing the unarguable.  If they don't exist, then you could assert
that you
can't do any kind of audit.  If you want to allow an audit, then whether you
allow
auditValue or AuditCapability doesn't matter a whit.  In this case, I'd just
allow it
for AuditValue, and not mess up AuditCapability.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, January 27, 2000 12:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Auditing Of Packages



You miss the point.  When an MG first starts up, there are no instantiated
ephemeral terminations.  As a result, you can't do an AuditValue on them.
It HAS to be AuditCapability.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Thursday, January 27, 2000 10:03 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:        RE: Auditing Of Packages

        The Audit Descriptor has DigitMap as one of its options,
so you can ask for a DigitMap.  The text says "DigitMap applied to the root
Termination returns all named DigitMaps in the gateway."
So I AuditValue does what you want.

        AuditCapability of DigitMap doesn't make any sense I think, and that
is what
the text says.

        Packages for ephemerals are solved by name patterns, which was
what started me out on that in the first place.  If you wildcard
auditValue a name pattern that equates to an ephemeral, and ask
for Packages, I think you get a list of packages that ephemeral
would support.

        So:
if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
might return
.....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?

n",....}}}}

        then
Context=-{W-AuditValue=Ephem*{Audit{Packages}}}

        should return the list of packages.

        While we could ask that this be made more explicit in the text,
no substantive change is warranted, I believe.

        Brian



        > -----Original Message-----
> From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
> Sent: Wednesday, January 26, 2000 9:23 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Auditing Of Packages
>
>
> Every termination should support digit map capability, so
> digit map names
> and values are all you would want to audit.  AuditValue is
> logical for that.
> This leaves packages, which happen to be tied into what types
> of ephemeral
> termination an MG will support.  Doctrine coming out of
> Washington was that
> you would find out the latter by digging out the termination
> naming pattern,
> then walking through  the naming tree to determine the capabilities
> supported by each branch.  As Chip points out immediately
> below, however,
> you cannot currently determine the packages supported by a
> termination until
> it has been instantiated.  It seems reasonable that
> AuditCapability also
> return a PackageList, the packages potentially supported by
> the termination
> as opposed to those actually invoked.
>
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>
>                     Section:        7.2.6, last line
>                     Category:       Technical
>                     Issue:          The draft text specifies
> that "DigitMap
> and Packages are
>                     not legal in AuditCapability". This is
> inconsistent with
> the return
>                     parameters shown for the example API.
> Furthermore, it
> would seem reasonable
>                     to be able determine what packages a
> termination (or
> gateway) supports as
>                     well as whether digit map is supported or
> not. Although
> packages can be
>                     audited with AuditValue, it would seem to
> make more
> sense to allow it in
>                     AuditCapability.
>                     Proposal:       It is proposed to strike the above
> sentence and allow for
>                     auditing of these two capabilities.
>
>                     v13 Status:     OPEN. No relevant text changed.
>
>                     Section:        7.2.6
>                     Category:       Open Issue
>                     Issue:          The current draft text
> does not specify
> how to audit
>                     ephemerals at startup. This issue was
> identified by the
> IETF editor but has
>                     not yet been resolved (issue 1). The
> issue is, that when
> you boot and have
>                     not yet created any ephemeral
> terminations, how do you
> know what the MG can
>                     do. For example, how do you know if the
> MG has say an IP
> interface, and ATM
>                     interface, an MPLS interface or a Frame
> Relay interface
> . If you could
>                     audit something, you could look at the
> "network" value
> in LocalControl.
>                     Discussion:             A continuation of
> the discussion
> that has occurred
>                     on the Megaco mailing list so far is
> needed in order to
> resolve the issue.
>
>                     v13 Status:     OPEN. No relevant text
> has been added.
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


------_=_NextPart_001_01BF68F1.B92F822E
Content-Type: text/html;
        charset="iso-8859-1"




RE: Auditing Of Packages




        You
are arguing the unarguable.  If they don't exist, then you could assert
that you
        

        can't
do any kind of audit.  If you want to allow an audit, then whether you
allow
        

        auditValue or AuditCapability doesn't matter a
whit.  In this case, I'd just allow it
        

        for
AuditValue, and not mess up AuditCapability.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Thursday, January 27, 2000
  12:39 PM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Auditing Of Packages

        
  
        You miss the point.  When an MG
  first starts up, there are no instantiated ephemeral terminations.  As a
  result, you can't do an AuditValue on them.  It HAS to be
  AuditCapability.
        
  
          
    
          -----Original Message----- 
          From:   Rosen, Brian [SMTP:brosen@fore.com] 
          Sent:   Thursday,
    January 27, 2000 10:03 AM 
          To:     Taylor, Tom-PT [CAR:B904:EXCH];
    MEGACO@standards.nortelnetworks.com 
          Subject:        RE: Auditing Of Packages 
          
    
          The Audit Descriptor has DigitMap as one of its
    options, 
          so you can ask for a
    DigitMap.  The text says "DigitMap applied to the root 
          Termination returns all named DigitMaps in the
    gateway." 
          So I AuditValue does what you
    want. 
          
    
          AuditCapability of DigitMap doesn't make any
    sense I think, and that is what 
          the text
    says. 
          
    
          Packages for ephemerals are solved by name
    patterns, which was 
          what started me out
    on that in the first place.  If you wildcard 
          auditValue a name pattern that equates to an ephemeral,
    and ask 
          for Packages, I think you get a
    list of packages that ephemeral 
          would
    support. 
          
    
          So: 
          if
    Context=-{Modify=Root{TerminationState{g/PatternNum=2}}} 
          might return 
          .....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?
    
          n",....}}}} 
          
    
          then 
          Context=-{W-AuditValue=Ephem*{Audit{Packages}}} 
          
    
          should return the list of packages. 
          
    
          While we could ask that this be made more
    explicit in the text, 
          no substantive
    change is warranted, I believe.  
          
    
          Brian 


          
    
          > -----Original Message----- 
          > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] 
          > Sent: Wednesday,
    January 26, 2000 9:23 PM 
          > To:
    MEGACO@standards.nortelnetworks.com 
          >
    Subject: Auditing Of Packages 
          >
    
          > 
          > Every termination should support digit map capability, so
    
          > digit map names 
          > and values are all you would want to audit. 
    AuditValue is 
          > logical for
    that. 
          > This leaves packages, which
    happen to be tied into what types 
          > of
    ephemeral 
          > termination an MG will
    support.  Doctrine coming out of 
          > Washington was that 
          > you
    would find out the latter by digging out the termination 
          > naming pattern, 
          > then walking through  the naming tree to determine the
    capabilities 
          > supported by each
    branch.  As Chip points out immediately 
          > below, however, 
          > you
    cannot currently determine the packages supported by a 
          > termination until 
          > it has been instantiated.  It seems reasonable that
    
          > AuditCapability also
    
          > return a PackageList, the packages
    potentially supported by 
          > the
    termination 
          > as opposed to those
    actually invoked. 
          > 
          > 
          >                    
    From:         Chip Sharp
    <chsharp@CISCO.COM> 
          >                    
    Subject:      Auditing 
          > 
          >                    
    Section:        7.2.6, last line
    
          >                    
    Category:       Technical 
          >                    
    Issue:          The draft text
    specifies 
          > that "DigitMap
    
          > and Packages are 
          >                    
    not legal in AuditCapability". This is 
          > inconsistent with 
          > the
    return 
          >                    
    parameters shown for the example API. 
          > Furthermore, it 
          > would
    seem reasonable 
          >                    
    to be able determine what packages a 
          >
    termination (or 
          > gateway) supports
    as 
          >                    
    well as whether digit map is supported or 
          > not. Although 
          > packages
    can be 
          >                    
    audited with AuditValue, it would seem to 
          > make more 
          > sense to allow
    it in 
          >                    
    AuditCapability. 
          >                    
    Proposal:       It is proposed to strike the
    above 
          > sentence and allow for
    
          >                    
    auditing of these two capabilities. 
          >
    
          >                    
    v13 Status:     OPEN. No relevant text changed.
    
          > 
          >                    
    Section:        7.2.6 
          >                    
    Category:       Open Issue 
          >                    
    Issue:          The current
    draft text 
          > does not specify
    
          > how to audit 
          >                    
    ephemerals at startup. This issue was 
          > identified by the 
          > IETF
    editor but has 
          >                    
    not yet been resolved (issue 1). The 
          >
    issue is, that when 
          > you boot and
    have 
          >                    
    not yet created any ephemeral 
          >
    terminations, how do you 
          > know what
    the MG can 
          >                    
    do. For example, how do you know if the 
          > MG has say an IP 
          >
    interface, and ATM 
          >                    
    interface, an MPLS interface or a Frame 
          > Relay interface 
          > . If you
    could 
          >                    
    audit something, you could look at the 
          > "network" value 
          > in
    LocalControl. 
          >                    
    Discussion:            
    A continuation of 
          > the
    discussion 
          > that has occurred
    
          >                    
    on the Megaco mailing list so far is 
          >
    needed in order to 
          > resolve the
    issue. 
          > 
          >                    
    v13 Status:     OPEN. No relevant text 
          > has been added. 
          > 
          > Tom Taylor
    
          > Advisor -- IPConnect Standards
    
          > E-mail: taylor@nortelnetworks.com
    (internally, Tom-PT Taylor) 
          > Phone
    and FAX: +1 613 736 0961 
          >
  
        

------_=_NextPart_001_01BF68F1.B92F822E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:30:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11488
	for ; Thu, 27 Jan 2000 13:30:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F18B6D0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:27:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11596 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:26:03 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0EAD63B0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          13:26:02 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 12:26:55 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 13:26:36 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 13:26:36 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68F4.0B09D188"
Message-ID:  
Date:         Thu, 27 Jan 2000 13:26:33 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Subtract Command with wildcard Termination Name
X-To:         Michael Thomas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68F4.0B09D188
Content-Type: text/plain;
        charset="iso-8859-1"

The catch is that ephemerals aren't there to Move in the first place.

We briefly discussed whether we really needed Move back in the thread "Move
not needed", 14-15 April 1999.  The argument then was that Move could be
done using an Add command with specified context.  Fernando Cuervo
counter-argued that one could exploit command similarity in implementation,
but gain in protocol clarity by having the separate commands.  At that time
this argument prevailed.

I'd swear I suggested Move to Null context somewhere back then and had my
wrist slapped for doing so, but I can't find the exchange at the moment.

Summary: we are where we are because the different commands have their own
distinct roles.  In particular, Move is restricted to transferring
terminations between active contexts, preserving state as much as possible
while doing so.

> -----Original Message-----
> From: Michael Thomas [SMTP:mat@CISCO.COM]
> Sent: Thursday, January 27, 2000 11:45 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Subtract Command with wildcard Termination Name
>
> Rosen, Brian writes:
>  > It is legal to move a termination to a new context, but we
>  > wanted to not allow that from null context.
>
>    Why is this? If you allowed it, it seems that
>    Add would just be a subset of Move.
>
>           Mike
>  >
>  > Brian
>  >
>  > > -----Original Message-----
>  > > From: samittal@hss.hns.com [mailto:samittal@hss.hns.com]
>  > > Sent: Thursday, January 27, 2000 12:59 AM
>  > > To: Rosen, Brian
>  > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > Subject: Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > >
>  > >
>  > > Agreed that "Choose in a ContextId is create a new one".
>  > > Does this mean that
>  > > in MOVE $ in ContextID is allowed (Move a termination to a
>  > > "new" context)? Or is
>  > > it that
>  > > $ in ContextID is only allowed in case of ADD?
>  > >
>  > > We need to add the following line somewhere in the text:
>  > > "A $ in ContextID means to CREATE a new context and except
>  > > ADD (and MOVE ??)
>  > > it can't appear in any other command"
>  > >
>  > > Regarding ContextID * and $ in Subtract our thinking was:
>  > > 1) ContextID * means "search for a termination in all
>  > > contexts and subtract from
>  > > it"
>  > > 2) ContextId $ means "find the context in which the
>  > > termination exists and
>  > > subtract it from that context"
>  > > By this logical meaning it seems that both are valid. But now
>  > > we agree to what
>  > > you say and (2) is not allowed.
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > > "Rosen, Brian"  on 01/27/2000 02:38:52 AM
>  > >
>  > > Please respond to "Rosen, Brian" 
>  > >
>  > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > cc:    (bcc: Sachin Mittal/HSS)
>  > >
>  > > Subject:  Re: Subtract Command with wildcard Termination Name
>  > >
>  > >
>  > >
>  > >
>  > > Just sent a couple of messages that address this:
>  > > Choose in a ContextId is create a new one
>  > >
>  > > Brian
>  > >
>  > > > -----Original Message-----
>  > > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>  > > > Sent: Tuesday, January 25, 2000 9:38 AM
>  > > > To: MEGACO@standards.nortelnetworks.com
>  > > > Subject: Re: Subtract Command with wildcard Termination Name
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > OK "*"  is allowed. Is "$" allowed ? Where MGC indicating MG
>  > > > that choose
>  > > >  the context  in which the given Termination exist and
>  > > > subtract the termination.
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > "Rosen, Brian"  on 01/25/2000 08:39:42 AM
>  > > >
>  > > > Please respond to "Rosen, Brian" 
>  > > >
>  > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > > cc:    (bcc: Sachin Mittal/HSS)
>  > > >
>  > > > Subject:  Re: Subtract Command with wildcard Termination Name
>  > > >
>  > > >
>  > > >
>  > > >
>  > > > I think this is headed in the wrong direction.  Subtract of
>  > > wildcarded
>  > > > contextId was explicitly allowed for,
>  > > > among other things, the response to a ServiceChange with mass
>  > > > out of service
>  > > > operations pending.
>  > > > The MGC must subtract all calls, and do it in a hurry.
>  > > >
>  > > > It is also useful in a wildcard Audit, with or without W-.
>  > > >
>  > > > So I think it is allowed, period.
>  > > >
>  > > > Brian
>  > > >
>  > > > -----Original Message-----
>  > > > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>  > > > Sent: Monday, January 24, 2000 10:06 AM
>  > > > To: MEGACO@standards.nortelnetworks.com
>  > > > Subject: Re: Subtract Command with wildcard Termiantion Name
>  > > >
>  > > >
>  > > >
>  > > > Your question has a couple of wider implications.  My first
>  > > > reaction was to
>  > > > say this was an error, because in principle the MGC can
>  > > > always know which
>  > > > context a termination is in, through audits if necessary.
>  > > > Then I checked
>  > > > out our audit response syntax and realized that the MGC
>  > > > cannot determine the
>  > > > current context of a termination if it doesn't know it already.
>  > > >
>  > > > I think the answer has to be that we change the production
>  > > > auditOther to
>  > > > include the context ID.
>  > > >
>  > > > e.g. auditOther = EQUAL TerminationID LBRKT  CtxToken EQUAL
>  > > ContextID
>  > > > terminationAudit RBRKT
>  > > >
>  > > > Then the answer to your original question is that it is an error.
>  > > >
>  > > >         -----Original Message-----
>  > > > From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>  > > > Sent:   Sunday, January 23, 2000 11:56 PM
>  > > > To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>  > > > Subject:        Subtract Command with wildcard Termiantion Name
>  > > >
>  > > >         Hi!
>  > > >      Here is a small query regarding the case where ContextID
>  > > > is "*" and
>  > > > Termination Name is fully-specified. Does this implies that
>  > > > MGC intends to
>  > > > Subtract the specific termination from
>  > > > "whichever" context it appears in ? Or it is an error because
>  > > > a termination
>  > > > can
>  > > > exist only in one context and
>  > > > ContextID = "*" for a specific termination is an error ?
>  > > >
>  > > >         Regards
>  > > > MadhuBabu
>  > > >
>  > > >
>  > > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  > >
>  >
>  >

------_=_NextPart_001_01BF68F4.0B09D188
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Subtract Command with wildcard Termination Name




        The catch is that =
ephemerals aren't there to Move in the first place.

        


        We briefly discussed =
whether we really needed Move back in the thread "Move not =
needed", 14-15 April 1999.  The argument then was that Move =
could be done using an Add command with specified context.  =
Fernando Cuervo counter-argued that one could exploit command =
similarity in implementation, but gain in protocol clarity by having =
the separate commands.  At that time this argument =
prevailed.
        


        I'd swear I =
suggested Move to Null context somewhere back then and had my wrist =
slapped for doing so, but I can't find the exchange at the =
moment.
        


        Summary: we are =
where we are because the different commands have their own distinct =
roles.  In particular, Move is restricted to transferring =
terminations between active contexts, preserving state as much as =
possible while doing so.
        

          

          -----Original Message-----

          From:   Michael Thomas [SMTP:mat@CISCO.COM]

          Sent:   Thursday, January 27, 2000 11:45 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Subtract Command with wildcard =
Termination Name

          


          Rosen, Brian writes:

           > It is legal to move a =
termination to a new context, but we

           > wanted to not allow that =
from null context.

          


             Why is this? If you =
allowed it, it seems that

             Add would just be a =
subset of Move.

          


                    =
Mike

           >

           > Brian

           >

           > > -----Original =
Message-----

           > > From: =
samittal@hss.hns.com [mailto:samittal@hss.hns.com]

           > > Sent: Thursday, =
January 27, 2000 12:59 AM

           > > To: Rosen, =
Brian

           > > Cc: =
MEGACO@STANDARDS.NORTELNETWORKS.COM

           > > Subject: Re: Subtract =
Command with wildcard Termination Name

           > >

           > >

           > >

           > >

           > > Agreed that =
"Choose in a ContextId is create a new one".

           > > Does this mean =
that

           > > in MOVE $ in =
ContextID is allowed (Move a termination to a

           > > "new" =
context)? Or is

           > > it that

           > > $ in ContextID is =
only allowed in case of ADD?

           > >

           > > We need to add the =
following line somewhere in the text:

           > > "A $ in =
ContextID means to CREATE a new context and except

           > > ADD (and MOVE =
??)

           > > it can't appear in =
any other command"

           > >

           > > Regarding ContextID * =
and $ in Subtract our thinking was:

           > > 1) ContextID * means =
"search for a termination in all

           > > contexts and subtract =
from

           > > it"

           > > 2) ContextId $ means =
"find the context in which the

           > > termination exists =
and

           > > subtract it from that =
context"

           > > By this logical =
meaning it seems that both are valid. But now

           > > we agree to =
what

           > > you say and (2) is =
not allowed.

           > >

           > >

           > >

           > >

           > >

           > >

           > >

           > >

           > >

           > > "Rosen, =
Brian" <brosen@FORE.COM> on 01/27/2000 02:38:52 AM

           > >

           > > Please respond to =
"Rosen, Brian" <brosen@FORE.COM>

           > >

           > > To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

           > > cc:    =
(bcc: Sachin Mittal/HSS)

           > >

           > > Subject:  Re: =
Subtract Command with wildcard Termination Name

           > >

           > >

           > >

           > >

           > > Just sent a couple of =
messages that address this:

           > > Choose in a ContextId =
is create a new one

           > >

           > > Brian

           > >

           > > > -----Original =
Message-----

           > > > From: Sachin =
Mittal [mailto:samittal@hss.hns.com]

           > > > Sent: Tuesday, =
January 25, 2000 9:38 AM

           > > > To: =
MEGACO@standards.nortelnetworks.com

           > > > Subject: Re: =
Subtract Command with wildcard Termination Name

           > > >

           > > >

           > > >

           > > >

           > > > OK =
"*"  is allowed. Is "$" allowed ? Where MGC =
indicating MG

           > > > that =
choose

           > > >  the =
context  in which the given Termination exist and

           > > > subtract the =
termination.

           > > >

           > > >

           > > >

           > > >

           > > > "Rosen, =
Brian" <brosen@FORE.COM> on 01/25/2000 08:39:42 AM

           > > >

           > > > Please respond =
to "Rosen, Brian" <brosen@FORE.COM>

           > > >

           > > > To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

           > > > =
cc:    (bcc: Sachin Mittal/HSS)

           > > >

           > > > Subject:  =
Re: Subtract Command with wildcard Termination Name

           > > >

           > > >

           > > >

           > > >

           > > > I think this is =
headed in the wrong direction.  Subtract of

           > > wildcarded

           > > > contextId was =
explicitly allowed for,

           > > > among other =
things, the response to a ServiceChange with mass

           > > > out of =
service

           > > > operations =
pending.

           > > > The MGC must =
subtract all calls, and do it in a hurry.

           > > >

           > > > It is also =
useful in a wildcard Audit, with or without W-.

           > > >

           > > > So I think it is =
allowed, period.

           > > >

           > > > Brian

           > > >

           > > > -----Original =
Message-----

           > > > From: Tom-PT =
Taylor [mailto:taylor@nortelnetworks.c=
om]

           > > > Sent: Monday, =
January 24, 2000 10:06 AM

           > > > To: =
MEGACO@standards.nortelnetworks.com

           > > > Subject: Re: =
Subtract Command with wildcard Termiantion Name

           > > >

           > > >

           > > >

           > > > Your question =
has a couple of wider implications.  My first

           > > > reaction was =
to

           > > > say this was an =
error, because in principle the MGC can

           > > > always know =
which

           > > > context a =
termination is in, through audits if necessary.

           > > > Then I =
checked

           > > > out our audit =
response syntax and realized that the MGC

           > > > cannot determine =
the

           > > > current context =
of a termination if it doesn't know it already.

           > > >

           > > > I think the =
answer has to be that we change the production

           > > > auditOther =
to

           > > > include the =
context ID.

           > > >

           > > > e.g. auditOther =
=3D EQUAL TerminationID LBRKT  CtxToken EQUAL

           > > ContextID

           > > > terminationAudit =
RBRKT

           > > >

           > > > Then the answer =
to your original question is that it is an error.

           > > >

           > > =
>         -----Original =
Message-----

           > > > =
From:   Sachin Mittal [SMTP:samittal@HSS.HNS.COM]

           > > > =
Sent:   Sunday, January 23, 2000 11:56 PM

           > > > =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

           > > > =
Subject:        Subtract Command =
with wildcard Termiantion Name

           > > >

           > > =
>         Hi!

           > > =
>      Here is a small query regarding the =
case where ContextID

           > > > is "*" =
and

           > > > Termination Name =
is fully-specified. Does this implies that

           > > > MGC intends =
to

           > > > Subtract the =
specific termination from

           > > > =
"whichever" context it appears in ? Or it is an error =
because

           > > > a =
termination

           > > > can

           > > > exist only in =
one context and

           > > > ContextID =3D =
"*" for a specific termination is an error ?

           > > >

           > > =
>         Regards

           > > > MadhuBabu

           > > >

           > > >

           > > >

           > >

           > >

           > >

           > >

           > >

           > >

           >

           >

          

        


------_=_NextPart_001_01BF68F4.0B09D188--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:41:49 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11715
	for ; Thu, 27 Jan 2000 13:41:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED37F360@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:39:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11619 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:37:40 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.AEAE1FC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          13:37:40 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 12:38:52 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 13:38:44 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 13:38:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68F5.BC134E22"
Message-ID:  
Date:         Thu, 27 Jan 2000 13:38:39 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Questions on Clause 7.1.9 of H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68F5.BC134E22
Content-Type: text/plain

Current text and ABNF do not allow embedding in signals descriptors.  As a
result, the second level of embedding cannot happen and the text needs no
clarification.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 9:32 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Questions on Clause 7.1.9 of H.248
>
        [[TomT]]  ...
> According to Section 7.1.9, can an embedded EventsDescriptor contain an
> embedded
> SignalsDescriptor?
>
> If it can, then the following is possible:  SignalsDescriptor (embedded
> Events
> Descriptor [embedded SignalsDescriptor]). In addition, then the following
> should
> be added to the next to last paragraph of 7.1.9:
>
> An embedded SignalsDescriptor may contain an embedded EventsDescriptor and
> vice
> versa.  However, only two levels of embedding are permitted.  For example,
> an
> embedded EventsDescriptor contained within an embedded Signals Descriptor
> shall
> not itself contain an embedded SignalsDescriptor.
>
> If this is not allowed, then the following should be added to the next to
> last
> paragraph of 7.1.9:
>
> An embedded SignalsDescriptor shall not contain an embedded
> EventsDescriptor.
>
>
> Section 3.2 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides proposals for clarifying this issue.
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF68F5.BC134E22
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Questions on Clause 7.1.9 of H.248




        Current text and =
ABNF do not allow embedding in signals descriptors.  As a result, =
the second level of embedding cannot happen and the text needs no =
clarification.
        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 9:32 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Questions on Clause =
7.1.9 of H.248

          


          [[TomT]]  ...

          According to Section 7.1.9, can an =
embedded EventsDescriptor contain an embedded

          SignalsDescriptor?

          


          If it can, then the following is =
possible:  SignalsDescriptor (embedded Events

          Descriptor [embedded =
SignalsDescriptor]). In addition, then the following should

          be added to the next to last =
paragraph of 7.1.9:

          


          An embedded SignalsDescriptor may =
contain an embedded EventsDescriptor and vice

          versa.  However, only two levels =
of embedding are permitted.  For example, an

          embedded EventsDescriptor contained =
within an embedded Signals Descriptor shall

          not itself contain an embedded =
SignalsDescriptor.

          


          If this is not allowed, then the =
following should be added to the next to last

          paragraph of 7.1.9:

          


          An embedded SignalsDescriptor shall =
not contain an embedded EventsDescriptor.

          

          


          Section 3.2 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides proposals for clarifying =
this issue.

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF68F5.BC134E22--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 13:47:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11849
	for ; Thu, 27 Jan 2000 13:47:45 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4D69EC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 13:45:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11642 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 13:44:24 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.9F3B6470@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          13:44:24 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 12:45:55 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 13:45:34
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 12:45:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF68F6.AC42CEEA"
Message-ID:  
Date:         Thu, 27 Jan 2000 12:45:24 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG16: Additional Notification from the MG to the MG
              C
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF68F6.AC42CEEA
Content-Type: text/plain

>
> When an ATM core network connection fails during the active state of a
> call, how
> does the network and call recover from this situation if at all?  Does the
> MG
> notify the MGC of this failure?  Does the MG that initiated the connection
> re-attempt the connection to the remote MG or do we wait until the caller
> or
> called party determines that the call has failed and sends a clearing
> indication
> to the network?
        [[TomT]]
        This may depend on implementation.  If the MG is designed to set up
and maintain the ATM connection itself, it may recover without telling the
MGC about the failure (but should report it in statistics sent up at the end
of the call).  More likely in my mind, the MG should send up a ServiceChange
indicating that the termination has failed and leave it up to the MGC to
decide what to do next.

> Another situation is the MG that is the recipient of the ATM connection
> request
> through the core network (e.g., it receives the ATM SETUP message and
> responds
> with an ATM CONNECT message).  In this case, this MG does not have a way
> to
> inform its serving MGC that the ATM connection has been established.
        [[TomT]]
        I'm waiting for the MSF to submit the ATM package they are supposed
to be sending us.  Nortel has submitted one already, and Cisco says another
is on the way (not sure of the authorship).

> At least two additional notifications may need to be supported between the
> MG
> and the MGC:
>

------_=_NextPart_001_01BF68F6.AC42CEEA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG16: Additional Notification from the MG to the =
MGC




         

          

          When an ATM core network connection =
fails during the active state of a call, how

          does the network and call recover =
from this situation if at all?  Does the MG

          notify the MGC of this failure?  =
Does the MG that initiated the connection

          re-attempt the connection to the =
remote MG or do we wait until the caller or

          called party determines that the call =
has failed and sends a clearing indication

          to the network?

          [[TomT]]  

          This may depend on =
implementation.  If the MG is designed to set up and maintain the =
ATM connection itself, it may recover without telling the MGC about the =
failure (but should report it in statistics sent up at the end of the =
call).  More likely in my mind, the MG should send up a =
ServiceChange indicating that the termination has failed and leave it =
up to the MGC to decide what to do next.
          


          Another situation is the MG that is =
the recipient of the ATM connection request

          through the core network (e.g., it =
receives the ATM SETUP message and responds

          with an ATM CONNECT message).  =
In this case, this MG does not have a way to

          inform its serving MGC that the ATM =
connection has been established.

          [[TomT]]  

          I'm waiting for the =
MSF to submit the ATM package they are supposed to be sending us.  =
Nortel has submitted one already, and Cisco says another is on the way =
(not sure of the authorship).
          


          At least two additional notifications =
may need to be supported between the MG

          and the MGC:

           

          

        


------_=_NextPart_001_01BF68F6.AC42CEEA--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 14:54:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13516
	for ; Thu, 27 Jan 2000 14:54:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.234D1ED0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 14:52:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11698 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 14:51:20 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F824D770@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          14:51:19 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 13:52:49 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 14:52:37
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 13:52:36 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6900.0DACCA4C"
Message-ID:  
Date:         Thu, 27 Jan 2000 13:52:32 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Auditing Of Packages
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6900.0DACCA4C
Content-Type: text/plain;
        charset="iso-8859-1"

What you're saying is that there is no semantic difference between
AuditValue and AuditCapability.  I hope you don't mean that.  We introduced
the distinction so we could audit separately the values actually set on a
termination vs. the choices offered to the MGC.  Packages on a non-existent
termination fall into the latter category -- they haven't been set yet.  The
whole point of the naming pattern and the W- wildcarding was so you could
walk through and determine what the MG could do on an aggregate basis before
you really got into call processing.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Thursday, January 27, 2000 1:13 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Auditing Of Packages
>
> You are arguing the unarguable.  If they don't exist, then you could
> assert that you
> can't do any kind of audit.  If you want to allow an audit, then whether
> you allow
> auditValue or AuditCapability doesn't matter a whit.  In this case, I'd
> just allow it
> for AuditValue, and not mess up AuditCapability.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Thursday, January 27, 2000 12:39 PM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Auditing Of Packages
>
>
>
>       You miss the point.  When an MG first starts up, there are no
> instantiated ephemeral terminations.  As a result, you can't do an
> AuditValue on them.  It HAS to be AuditCapability.
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@fore.com]
>       Sent:   Thursday, January 27, 2000 10:03 AM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@standards.nortelnetworks.com
>       Subject:        RE: Auditing Of Packages
>
>               The Audit Descriptor has DigitMap as one of its options,
>       so you can ask for a DigitMap.  The text says "DigitMap applied to
> the root
>       Termination returns all named DigitMaps in the gateway."
>       So I AuditValue does what you want.
>
>               AuditCapability of DigitMap doesn't make any sense I think,
> and that is what
>       the text says.
>
>               Packages for ephemerals are solved by name patterns, which
> was
>       what started me out on that in the first place.  If you wildcard
>       auditValue a name pattern that equates to an ephemeral, and ask
>       for Packages, I think you get a list of packages that ephemeral
>       would support.
>
>               So:
>       if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
>       might return
>
> .....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?
> n?
>       n",....}}}}
>
>               then
>       Context=-{W-AuditValue=Ephem*{Audit{Packages}}}
>
>               should return the list of packages.
>
>               While we could ask that this be made more explicit in the
> text,
>       no substantive change is warranted, I believe.
>
>               Brian
>
>
>
>               > -----Original Message-----
>       > From: Tom-PT Taylor [ ]
>       > Sent: Wednesday, January 26, 2000 9:23 PM
>       > To: MEGACO@standards.nortelnetworks.com
>       > Subject: Auditing Of Packages
>       >
>       >
>       > Every termination should support digit map capability, so
>       > digit map names
>       > and values are all you would want to audit.  AuditValue is
>       > logical for that.
>       > This leaves packages, which happen to be tied into what types
>       > of ephemeral
>       > termination an MG will support.  Doctrine coming out of
>       > Washington was that
>       > you would find out the latter by digging out the termination
>       > naming pattern,
>       > then walking through  the naming tree to determine the
> capabilities
>       > supported by each branch.  As Chip points out immediately
>       > below, however,
>       > you cannot currently determine the packages supported by a
>       > termination until
>       > it has been instantiated.  It seems reasonable that
>       > AuditCapability also
>       > return a PackageList, the packages potentially supported by
>       > the termination
>       > as opposed to those actually invoked.
>       >
>       >
>       >                     From:         Chip Sharp 
>       >                     Subject:      Auditing
>       >
>       >                     Section:        7.2.6, last line
>       >                     Category:       Technical
>       >                     Issue:          The draft text specifies
>       > that "DigitMap
>       > and Packages are
>       >                     not legal in AuditCapability". This is
>       > inconsistent with
>       > the return
>       >                     parameters shown for the example API.
>       > Furthermore, it
>       > would seem reasonable
>       >                     to be able determine what packages a
>       > termination (or
>       > gateway) supports as
>       >                     well as whether digit map is supported or
>       > not. Although
>       > packages can be
>       >                     audited with AuditValue, it would seem to
>       > make more
>       > sense to allow it in
>       >                     AuditCapability.
>       >                     Proposal:       It is proposed to strike the
> above
>       > sentence and allow for
>       >                     auditing of these two capabilities.
>       >
>       >                     v13 Status:     OPEN. No relevant text
> changed.
>       >
>       >                     Section:        7.2.6
>       >                     Category:       Open Issue
>       >                     Issue:          The current draft text
>       > does not specify
>       > how to audit
>       >                     ephemerals at startup. This issue was
>       > identified by the
>       > IETF editor but has
>       >                     not yet been resolved (issue 1). The
>       > issue is, that when
>       > you boot and have
>       >                     not yet created any ephemeral
>       > terminations, how do you
>       > know what the MG can
>       >                     do. For example, how do you know if the
>       > MG has say an IP
>       > interface, and ATM
>       >                     interface, an MPLS interface or a Frame
>       > Relay interface
>       > . If you could
>       >                     audit something, you could look at the
>       > "network" value
>       > in LocalControl.
>       >                     Discussion:             A continuation of
>       > the discussion
>       > that has occurred
>       >                     on the Megaco mailing list so far is
>       > needed in order to
>       > resolve the issue.
>       >
>       >                     v13 Status:     OPEN. No relevant text
>       > has been added.
>       >
>       > Tom Taylor
>       > Advisor -- IPConnect Standards
>       > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
>       > Phone and FAX: +1 613 736 0961
>       >
>

------_=_NextPart_001_01BF6900.0DACCA4C
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Auditing Of Packages




        What you're saying =
is that there is no semantic difference between AuditValue and =
AuditCapability.  I hope you don't mean that.  We introduced =
the distinction so we could audit separately the values actually set on =
a termination vs. the choices offered to the MGC.  Packages on a =
non-existent termination fall into the latter category -- they haven't =
been set yet.  The whole point of the naming pattern and the W- =
wildcarding was so you could walk through and determine what the MG =
could do on an aggregate basis before you really got into call =
processing.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Thursday, January 27, 2000 1:13 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Auditing Of Packages

          


          You are arguing the =
unarguable.=A0 If they don't exist, then you could assert that =
you

          can't do any kind =
of audit.=A0 If you want to allow an audit, then whether you =
allow

          auditValue or =
AuditCapability doesn't matter a whit.=A0 In this case, I'd just allow =
it

          for AuditValue, and =
not mess up AuditCapability.

          =A0

          Brian

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Thursday, January 27, 2000 12:39 PM
            
            To: MEGACO@standards.nortelnetworks.com
            
            Subject: Re: Auditing Of Packages
            

            
            

            


            You miss the =
point.=A0 When an MG first starts up, there are no instantiated =
ephemeral terminations.=A0 As a result, you can't do an AuditValue on =
them.=A0 It HAS to be AuditCapability.
            


                    -----Original Message-----
            
            From:=A0=A0 Rosen, Brian =
[SMTP:brosen@fore.com]
            
            Sent:=A0=A0 Thursday, January =
27, 2000 10:03 AM
            
            To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Auditing Of =
Packages 

            


                    The Audit Descriptor has DigitMap as one of its =
options,
            
            so you can ask for a DigitMap.=A0 =
The text says "DigitMap applied to the root
            
            Termination returns all named =
DigitMaps in the gateway."
            
            So I AuditValue does what you =
want. 

            


                    AuditCapability of DigitMap doesn't make any sense I =
think, and that is what
            
            the text says. 

            


                    Packages for ephemerals are solved by name patterns, =
which was
            
            what started me out on that in the =
first place.=A0 If you wildcard
            
auditValue a name pattern that equates to =
an ephemeral, and ask
            
            for Packages, I think you get a =
list of packages that ephemeral
            
            would support. 

            


                    So:
            
            if =
Context=3D-{Modify=3DRoot{TerminationState{g/PatternNum=3D2}}}
            
            might return
            
            .....TerminationState(g/MaxPatterns=3D4,g/PatternNum=3D2,=
g/Pattern=3D"Ephem?n?n?n?
            
            n",....}}}} 

            


                    then
            
            Context=3D-{W-AuditValue=3DEphem*{Audit{Packages}}} 

            


                    should return the list of packages. 

            


                    While we could ask that this be made more explicit in =
the text,
            
            no substantive change is =
warranted, I believe.=A0=20

            


                    Brian 

            

            

            


                    > -----Original Message-----
            
            > From: Tom-PT Taylor =
[ <mailto:taylor@nortelnetworks.c=
om>]
            
            > Sent: Wednesday, January 26, =
2000 9:23 PM
            
            > To: =
MEGACO@standards.nortelnetworks.com
            
            > Subject: Auditing Of =
Packages
            
            >
            
>
            
> Every termination should support =
digit map capability, so
            
> digit map names
            
            > and values are all you would =
want to audit.=A0 AuditValue is
            
> logical for that.
            
            > This leaves packages, which =
happen to be tied into what types
            
> of ephemeral
            
            > termination an MG will =
support.=A0 Doctrine coming out of
            
> Washington was that
            
            > you would find out the latter =
by digging out the termination
            
> naming pattern,
            
            > then walking through=A0 the =
naming tree to determine the capabilities
            
            > supported by each branch.=A0 =
As Chip points out immediately
            
> below, however,
            
            > you cannot currently =
determine the packages supported by a
            
> termination until
            
            > it has been instantiated.=A0 =
It seems reasonable that
            
> AuditCapability also
            
            > return a PackageList, the =
packages potentially supported by
            
> the termination
            
            > as opposed to those actually =
invoked.
            
            >
            
>
            
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 From:=A0=A0=A0=A0=A0=A0=A0=A0 Chip Sharp =
<chsharp@CISCO.COM>
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Subject:=A0=A0=A0=A0=A0 Auditing
            
            >
            
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6, last line
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Technical
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The draft text =
specifies
            
> that "DigitMap
            
            > and Packages are
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not legal in AuditCapability". This is
            
> inconsistent with
            
            > the return
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 parameters shown for the example API.
            
> Furthermore, it
            
            > would seem =
reasonable
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 to be able determine what packages a
            
> termination (or
            
            > gateway) supports =
as
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 well as whether digit map is supported or
            
> not. Although
            
            > packages can be
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audited with AuditValue, it would seem to
            
> make more
            
            > sense to allow it =
in
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 AuditCapability.
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Proposal:=A0=A0=A0=A0=A0=A0 It is proposed =
to strike the above
            
            > sentence and allow =
for
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 auditing of these two capabilities.
            
            >
            
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text =
changed.
            
            >
            
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Open Issue
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The current draft =
text
            
> does not specify
            
            > how to audit
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 ephemerals at startup. This issue was
            
> identified by the
            
            > IETF editor but =
has
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet been resolved (issue 1). The
            
> issue is, that when
            
            > you boot and have
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet created any ephemeral
            
> terminations, how do you
            
            > know what the MG =
can
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 do. For example, how do you know if the
            
> MG has say an IP
            
            > interface, and =
ATM
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 interface, an MPLS interface or a Frame
            
> Relay interface
            
            > . If you could
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audit something, you could look at the
            
> "network" =
value
            
            > in LocalControl.
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Discussion:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A continuation =
of
            
> the discussion
            
            > that has occurred
            
            >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 on the Megaco mailing list so far is
            
> needed in order to
            
            > resolve the =
issue.
            
            >
            
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text
            
> has been added.
            
            >
            
> Tom Taylor
            
            > Advisor -- IPConnect =
Standards
            
            > E-mail: =
taylor@nortelnetworks.com (internally, Tom-PT Taylor)
            
            > Phone and FAX: +1 613 736 =
0961
            
            >=20

            

        


------_=_NextPart_001_01BF6900.0DACCA4C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:13:00 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13866
	for ; Thu, 27 Jan 2000 15:12:54 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A8775240@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:10:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11729 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:09:00 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.70DD9E20@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:09:00 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:10:40 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 15:10:27
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 14:10:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6902.8D1A37E0"
Message-ID:  
Date:         Thu, 27 Jan 2000 14:10:25 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Comments on Command Error Codes,
              7.3 of H.24 8
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6902.8D1A37E0
Content-Type: text/plain

IMHO, technology-specific codes like this should be added in packages rather
than the main document.  We need to review our current list of codes with
this in mind.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 9:09 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Comments on Command Error Codes, 7.3 of
> H.248
>
> When the MGC requests the MG to add a physical termination to a context,
> let us
> say, an analog line, it is possible that the actual physical interface
> from the
> MG to the customer premises could use one of a number of transport
> technologies
> (e.g., Integrated Digital Loop Carrier [IDLC] as defined in ITU-T
> Recommendation
> G.xxx).  In some cases, it may be possible for the actual line to be
> in-service,
> but there may be congestion in the path to the physical line.  An error
> code is
> needed to report such a case to the MGC (e.g., access facility busy) as a
> response to an AddRequest command.
>
> The following command error code should be added to Section 7.3:
>
>       532 Access Facility Busy.
>
>
> Section 3.4 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides a proposal for clarifying this issue.
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF6902.8D1A37E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Comments on Command Error Codes, 7.3 of =
H.248




        IMHO, =
technology-specific codes like this should be added in packages rather =
than the main document.  We need to review our current list of =
codes with this in mind.
        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 9:09 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Comments on Command =
Error Codes, 7.3 of H.248

          


          When the MGC requests the MG to add a =
physical termination to a context, let us

          say, an analog line, it is possible =
that the actual physical interface from the

          MG to the customer premises could use =
one of a number of transport technologies

          (e.g., Integrated Digital Loop =
Carrier [IDLC] as defined in ITU-T Recommendation

          G.xxx).  In some cases, it may =
be possible for the actual line to be in-service,

          but there may be congestion in the =
path to the physical line.  An error code is

          needed to report such a case to the =
MGC (e.g., access facility busy) as a

          response to an AddRequest =
command.

          


          The following command error code =
should be added to Section 7.3:

          


                532 =
Access Facility Busy.

          

          


          Section 3.4 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides a proposal for clarifying =
this issue.

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF6902.8D1A37E0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:15:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13893
	for ; Thu, 27 Jan 2000 15:15:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F061F740@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:12:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11714 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:11:22 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5F9DAED0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:01:22
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id PAA23492; Thu, 27 Jan
          2000 15:03:08 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id PAA00635; Thu, 27 Jan
          2000 15:03:11 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Thu, 27 Jan 2000 15:00:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6901.1B56C67E"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20884C@whq-msgusr-02.fore.com>
Date:         Thu, 27 Jan 2000 15:03:07 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Auditing Of Packages
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6901.1B56C67E
Content-Type: text/plain;
        charset="iso-8859-1"

The whole idea of auditing packages "breaks" the distinction between
AuditValue and
AuditCapability.  You can make an argument that Packages should be legal in
either,
but there aren't two interesting things you can get with Packages, so we
decided that
they were legal in AuditValue, and not in AuditCapabilities.  We could have
decided the
other way, and there would be no difference, the decision was arbitrary.
I don't think there is any way you can assert there is any difference
between Package
audit of a physical termination and package audit of a (non instantiated)
ephemeral
termination which would lead you to argue that package audit of one should
be in AuditValue
while package audit of the other should be in AuditCapability.  Neither ever
has
"possible values" or "current values".  They both indicate "packages
implemented",
which is neither a possible or a current value.

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, January 27, 2000 2:53 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Auditing Of Packages



What you're saying is that there is no semantic difference between
AuditValue and AuditCapability.  I hope you don't mean that.  We introduced
the distinction so we could audit separately the values actually set on a
termination vs. the choices offered to the MGC.  Packages on a non-existent
termination fall into the latter category -- they haven't been set yet.  The
whole point of the naming pattern and the W- wildcarding was so you could
walk through and determine what the MG could do on an aggregate basis before
you really got into call processing.

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Thursday, January 27, 2000 1:13 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:        RE: Auditing Of Packages

        You are arguing the unarguable.  If they don't exist, then you could
assert that you
can't do any kind of audit.  If you want to allow an audit, then whether you
allow
auditValue or AuditCapability doesn't matter a whit.  In this case, I'd just
allow it
for AuditValue, and not mess up AuditCapability.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Thursday, January 27, 2000 12:39 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Auditing Of Packages



        You miss the point.  When an MG first starts up, there are no
instantiated ephemeral terminations.  As a result, you can't do an
AuditValue on them.  It HAS to be AuditCapability.

                -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Thursday, January 27, 2000 10:03 AM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:        RE: Auditing Of Packages

                The Audit Descriptor has DigitMap as one of its options,
so you can ask for a DigitMap.  The text says "DigitMap applied to the root
Termination returns all named DigitMaps in the gateway."
So I AuditValue does what you want.

                AuditCapability of DigitMap doesn't make any sense I think,
and that is what
the text says.

                Packages for ephemerals are solved by name patterns, which
was
what started me out on that in the first place.  If you wildcard
auditValue a name pattern that equates to an ephemeral, and ask
for Packages, I think you get a list of packages that ephemeral
would support.

                So:
if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
might return
.....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?
n",....}}}}

                then
Context=-{W-AuditValue=Ephem*{Audit{Packages}}}

                should return the list of packages.

                While we could ask that this be made more explicit in the
text,
no substantive change is warranted, I believe.

                Brian



                > -----Original Message-----
> From: Tom-PT Taylor [ < mailto:taylor@nortelnetworks.com
 >]
> Sent: Wednesday, January 26, 2000 9:23 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Auditing Of Packages
>
>
> Every termination should support digit map capability, so
> digit map names
> and values are all you would want to audit.  AuditValue is
> logical for that.
> This leaves packages, which happen to be tied into what types
> of ephemeral
> termination an MG will support.  Doctrine coming out of
> Washington was that
> you would find out the latter by digging out the termination
> naming pattern,
> then walking through  the naming tree to determine the capabilities
> supported by each branch.  As Chip points out immediately
> below, however,
> you cannot currently determine the packages supported by a
> termination until
> it has been instantiated.  It seems reasonable that
> AuditCapability also
> return a PackageList, the packages potentially supported by
> the termination
> as opposed to those actually invoked.
>
>
>                     From:         Chip Sharp 
>                     Subject:      Auditing
>
>                     Section:        7.2.6, last line
>                     Category:       Technical
>                     Issue:          The draft text specifies
> that "DigitMap
> and Packages are
>                     not legal in AuditCapability". This is
> inconsistent with
> the return
>                     parameters shown for the example API.
> Furthermore, it
> would seem reasonable
>                     to be able determine what packages a
> termination (or
> gateway) supports as
>                     well as whether digit map is supported or
> not. Although
> packages can be
>                     audited with AuditValue, it would seem to
> make more
> sense to allow it in
>                     AuditCapability.
>                     Proposal:       It is proposed to strike the above
> sentence and allow for
>                     auditing of these two capabilities.
>
>                     v13 Status:     OPEN. No relevant text changed.
>
>                     Section:        7.2.6
>                     Category:       Open Issue
>                     Issue:          The current draft text
> does not specify
> how to audit
>                     ephemerals at startup. This issue was
> identified by the
> IETF editor but has
>                     not yet been resolved (issue 1). The
> issue is, that when
> you boot and have
>                     not yet created any ephemeral
> terminations, how do you
> know what the MG can
>                     do. For example, how do you know if the
> MG has say an IP
> interface, and ATM
>                     interface, an MPLS interface or a Frame
> Relay interface
> . If you could
>                     audit something, you could look at the
> "network" value
> in LocalControl.
>                     Discussion:             A continuation of
> the discussion
> that has occurred
>                     on the Megaco mailing list so far is
> needed in order to
> resolve the issue.
>
>                     v13 Status:     OPEN. No relevant text
> has been added.
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


------_=_NextPart_001_01BF6901.1B56C67E
Content-Type: text/html;
        charset="iso-8859-1"




RE: Auditing Of Packages




        The
whole idea of auditing packages "breaks" the distinction between AuditValue
and
        

        AuditCapability.  You can make an argument that
Packages should be legal in either,
        

        but
there aren't two interesting things you can get with Packages, so we decided
that
        

        they
were legal in AuditValue, and not in AuditCapabilities.  We could have
decided the
        

        other
way, and there would be no difference, the decision was arbitrary. 

        

        I
don't think there is any way you can assert there is any difference
between Package 
        

        audit
of a physical termination and package audit of a (non
instantiated) ephemeral 
        

        termination which would lead you to argue
that package audit of one should be in AuditValue
        

        while
package audit of the other should be in AuditCapability.  Neither ever
has
        

        "possible values" or "current values".  They both
indicate "packages implemented",
        

        which
is neither a possible or a current value.
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Thursday, January 27, 2000
  2:53 PM
        To: Rosen, Brian;
  megaco@standards.nortelnetworks.com
        Subject: RE: Auditing Of
  Packages

        
  
        What you're saying is that there is
  no semantic difference between AuditValue and AuditCapability.  I hope
  you don't mean that.  We introduced the distinction so we could audit
  separately the values actually set on a termination vs. the choices offered to
  the MGC.  Packages on a non-existent termination fall into the latter
  category -- they haven't been set yet.  The whole point of the naming
  pattern and the W- wildcarding was so you could walk through and determine
  what the MG could do on an aggregate basis before you really got into call
  processing.
        
  
          
    
          -----Original Message----- 
          From:   Rosen, Brian [SMTP:brosen@fore.com] 
          Sent:   Thursday,
    January 27, 2000 1:13 PM 
          To:     Taylor, Tom-PT [CAR:B904:EXCH];
    MEGACO@standards.nortelnetworks.com 
          Subject:        RE: Auditing Of Packages 
          
    
          You are arguing the
    unarguable.  If they don't exist, then you could assert that you
    
          can't do any kind of audit. 
    If you want to allow an audit, then whether you allow 
          auditValue or AuditCapability doesn't matter
    a whit.  In this case, I'd just allow it 
          for AuditValue, and not mess up AuditCapability.
    
            
          Brian 
          
    
            
      
            -----Original Message-----
            From: Tom-PT Taylor
      [mailto:taylor@nortelnetworks.com]
            Sent: Thursday, January 27,
      2000 12:39 PM
            To: MEGACO@standards.nortelnetworks.com
            Subject: Re:
      Auditing Of Packages

            
      
            You miss the point.  When an
      MG first starts up, there are no instantiated ephemeral
      terminations.  As a result, you can't do an AuditValue on them. 
      It HAS to be AuditCapability.
            
      
                    -----Original Message-----
            From:   Rosen, Brian [SMTP:brosen@fore.com]
            Sent:   Thursday, January 27, 2000 10:03 AM
            To:    
      Taylor, Tom-PT [CAR:B904:EXCH];
      MEGACO@standards.nortelnetworks.com
            Subject:        RE: Auditing Of
      Packages 
            
      
                    The
      Audit Descriptor has DigitMap as one of its options,
            so you can ask for a
      DigitMap.  The text says "DigitMap applied to the root
            Termination returns all
      named DigitMaps in the gateway."
            So I AuditValue does what you want. 
            
      
                    AuditCapability of DigitMap doesn't make any sense I think, and
      that is what
            the
      text says. 
            
      
                    Packages for ephemerals are solved by name patterns, which
      was
            what started
      me out on that in the first place.  If you wildcard
            auditValue a name pattern that equates to an ephemeral,
      and ask
            for
      Packages, I think you get a list of packages that ephemeral
            would support. 
            
      
                    So:
            if
      Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
            might return
            .....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?n?
            n",....}}}} 
            
      
                    then
            Context=-{W-AuditValue=Ephem*{Audit{Packages}}} 
            
      
                    should return the list of packages.
      
            
      
                    While we could ask that this be made more explicit in the
      text,
            no
      substantive change is warranted, I believe.  
            
      
                    Brian 


            
      
                    >
      -----Original Message-----
            > From: Tom-PT Taylor [ <mailto:taylor@nortelnetworks.com>]
            > Sent: Wednesday, January 26, 2000 9:23 PM
            > To:
      MEGACO@standards.nortelnetworks.com
            > Subject: Auditing Of
      Packages
            >
            >
            > Every termination should support digit map
      capability, so
            > digit map
      names
            > and
      values are all you would want to audit.  AuditValue
      is
            > logical for that.
            > This leaves packages,
      which happen to be tied into what types
            > of ephemeral
            > termination an MG will support.  Doctrine
      coming out of
            > Washington was
      that
            > you
      would find out the latter by digging out the termination
            > naming pattern,
            > then walking
      through  the naming tree to determine the capabilities
            > supported by each
      branch.  As Chip points out immediately
            > below, however,
            > you cannot currently determine the packages
      supported by a
            > termination
      until
            > it
      has been instantiated.  It seems reasonable that
            > AuditCapability also
            > return a PackageList,
      the packages potentially supported by
            > the termination
            > as opposed to those actually invoked.
            >
            >
            >                    
      From:         Chip Sharp
      <chsharp@CISCO.COM>
            >                    
      Subject:      Auditing
            >
            >                    
      Section:        7.2.6, last
      line
            >                    
      Category:       Technical
            >                    
      Issue:          The draft
      text specifies
            > that
      "DigitMap
            >
      and Packages are
            >                    
      not legal in AuditCapability". This is
            > inconsistent with
            > the return
            >                    
      parameters shown for the example API.
            > Furthermore, it
            > would seem reasonable
            >                    
      to be able determine what packages a
            > termination (or
            > gateway) supports as
            >                    
      well as whether digit map is supported or
            > not. Although
            > packages can be
            >                    
      audited with AuditValue, it would seem to
            > make more
            > sense to allow it in
            >                    
      AuditCapability.
            >                    
      Proposal:       It is proposed to strike the
      above
            >
      sentence and allow for
            >                    
      auditing of these two capabilities.
            >
            >                    
      v13 Status:     OPEN. No relevant text
      changed.
            >
            >                    
      Section:        7.2.6
            >                    
      Category:       Open Issue
            >                    
      Issue:          The current
      draft text
            > does not
      specify
            > how
      to audit
            >                    
      ephemerals at startup. This issue was
            > identified by the
            > IETF editor but has
            >                    
      not yet been resolved (issue 1). The
            > issue is, that when
            > you boot and have
            >                    
      not yet created any ephemeral
            >
      terminations, how do you
            > know what the MG can
            >                    
      do. For example, how do you know if the
            > MG has say an IP
            > interface, and ATM
            >                    
      interface, an MPLS interface or a Frame
            > Relay interface
            > . If you could
            >                    
      audit something, you could look at the
            > "network" value
            > in LocalControl.
            >                    
      Discussion:            
      A continuation of
            > the
      discussion
            >
      that has occurred
            >                    
      on the Megaco mailing list so far is
            > needed in order to
            > resolve the issue.
            >
            >                    
      v13 Status:     OPEN. No relevant text
            > has been added.
            >
            > Tom Taylor
            > Advisor -- IPConnect Standards
            > E-mail:
      taylor@nortelnetworks.com (internally, Tom-PT Taylor)
            > Phone and FAX: +1 613
      736 0961
            > 
        

------_=_NextPart_001_01BF6901.1B56C67E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:27:16 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14015
	for ; Thu, 27 Jan 2000 15:27:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E4F2750@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:24:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11751 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:22:39 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.58998AC0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:22:38 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:24:05 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 15:23:47
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 14:23:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6904.684CEA00"
Message-ID:  
Date:         Thu, 27 Jan 2000 14:23:34 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Auditing Of Packages
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6904.684CEA00
Content-Type: text/plain;
        charset="iso-8859-1"

I had figured that AuditValue would return "packages actually invoked in
properties set for this termination".  There's an important distinction
between that and "properties that could be invoked for a termination with
this name pattern" -- the latter, for instance, might reveal that the GW
supports both ATM and RTP ephemerals using the same simple numeric name for
each, while the AuditValue would reveal that this particular instantiated
termination has an ATM package on it.

The issue of determining MG transport capabilities and the nature of
ephemeral terminations is not closed until we close on this one.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Thursday, January 27, 2000 3:03 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; megaco@standards.nortelnetworks.com
> Subject:      RE: Auditing Of Packages
>
> The whole idea of auditing packages "breaks" the distinction between
> AuditValue and
> AuditCapability.  You can make an argument that Packages should be legal
> in either,
> but there aren't two interesting things you can get with Packages, so we
> decided that
> they were legal in AuditValue, and not in AuditCapabilities.  We could
> have decided the
> other way, and there would be no difference, the decision was arbitrary.
> I don't think there is any way you can assert there is any difference
> between Package
> audit of a physical termination and package audit of a (non instantiated)
> ephemeral
> termination which would lead you to argue that package audit of one should
> be in AuditValue
> while package audit of the other should be in AuditCapability.  Neither
> ever has
> "possible values" or "current values".  They both indicate "packages
> implemented",
> which is neither a possible or a current value.
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Thursday, January 27, 2000 2:53 PM
>       To: Rosen, Brian; megaco@standards.nortelnetworks.com
>       Subject: RE: Auditing Of Packages
>
>
>
>       What you're saying is that there is no semantic difference between
> AuditValue and AuditCapability.  I hope you don't mean that.  We
> introduced the distinction so we could audit separately the values
> actually set on a termination vs. the choices offered to the MGC.
> Packages on a non-existent termination fall into the latter category --
> they haven't been set yet.  The whole point of the naming pattern and the
> W- wildcarding was so you could walk through and determine what the MG
> could do on an aggregate basis before you really got into call processing.
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@fore.com]
>       Sent:   Thursday, January 27, 2000 1:13 PM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@standards.nortelnetworks.com
>       Subject:        RE: Auditing Of Packages
>
>               You are arguing the unarguable.  If they don't exist, then
> you could assert that you
>       can't do any kind of audit.  If you want to allow an audit, then
> whether you allow
>       auditValue or AuditCapability doesn't matter a whit.  In this case,
> I'd just allow it
>       for AuditValue, and not mess up AuditCapability.
>
>       Brian
>
>                       -----Original Message-----
>               From: Tom-PT Taylor [ ]
>               Sent: Thursday, January 27, 2000 12:39 PM
>               To: MEGACO@standards.nortelnetworks.com
>               Subject: Re: Auditing Of Packages
>
>
>
>                       You miss the point.  When an MG first starts up,
> there are no instantiated ephemeral terminations.  As a result, you can't
> do an AuditValue on them.  It HAS to be AuditCapability.
>
>                               -----Original Message-----
>               From:   Rosen, Brian [SMTP:brosen@fore.com]
>               Sent:   Thursday, January 27, 2000 10:03 AM
>               To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@standards.nortelnetworks.com
>               Subject:        RE: Auditing Of Packages
>
>                               The Audit Descriptor has DigitMap as one of
> its options,
>               so you can ask for a DigitMap.  The text says "DigitMap
> applied to the root
>               Termination returns all named DigitMaps in the gateway."
>               So I AuditValue does what you want.
>
>                               AuditCapability of DigitMap doesn't make any
> sense I think, and that is what
>               the text says.
>
>                               Packages for ephemerals are solved by name
> patterns, which was
>               what started me out on that in the first place.  If you
> wildcard
>               auditValue a name pattern that equates to an ephemeral, and
> ask
>               for Packages, I think you get a list of packages that
> ephemeral
>               would support.
>
>                               So:
>               if Context=-{Modify=Root{TerminationState{g/PatternNum=2}}}
>               might return
>
> .....TerminationState(g/MaxPatterns=4,g/PatternNum=2,g/Pattern="Ephem?n?n?
> n?
>               n",....}}}}
>
>                               then
>               Context=-{W-AuditValue=Ephem*{Audit{Packages}}}
>
>                               should return the list of packages.
>
>                               While we could ask that this be made more
> explicit in the text,
>               no substantive change is warranted, I believe.
>
>                               Brian
>
>
>
>                               > -----Original Message-----
>               > From: Tom-PT Taylor [ <
> >]
>               > Sent: Wednesday, January 26, 2000 9:23 PM
>               > To: MEGACO@standards.nortelnetworks.com
>               > Subject: Auditing Of Packages
>               >
>               >
>               > Every termination should support digit map capability, so
>               > digit map names
>               > and values are all you would want to audit.  AuditValue is
>               > logical for that.
>               > This leaves packages, which happen to be tied into what
> types
>               > of ephemeral
>               > termination an MG will support.  Doctrine coming out of
>               > Washington was that
>               > you would find out the latter by digging out the
> termination
>               > naming pattern,
>               > then walking through  the naming tree to determine the
> capabilities
>               > supported by each branch.  As Chip points out immediately
>               > below, however,
>               > you cannot currently determine the packages supported by a
>               > termination until
>               > it has been instantiated.  It seems reasonable that
>               > AuditCapability also
>               > return a PackageList, the packages potentially supported
> by
>               > the termination
>               > as opposed to those actually invoked.
>               >
>               >
>               >                     From:         Chip Sharp
> 
>               >                     Subject:      Auditing
>               >
>               >                     Section:        7.2.6, last line
>               >                     Category:       Technical
>               >                     Issue:          The draft text
> specifies
>               > that "DigitMap
>               > and Packages are
>               >                     not legal in AuditCapability". This is
>               > inconsistent with
>               > the return
>               >                     parameters shown for the example API.
>               > Furthermore, it
>               > would seem reasonable
>               >                     to be able determine what packages a
>               > termination (or
>               > gateway) supports as
>               >                     well as whether digit map is supported
> or
>               > not. Although
>               > packages can be
>               >                     audited with AuditValue, it would seem
> to
>               > make more
>               > sense to allow it in
>               >                     AuditCapability.
>               >                     Proposal:       It is proposed to
> strike the above
>               > sentence and allow for
>               >                     auditing of these two capabilities.
>               >
>               >                     v13 Status:     OPEN. No relevant text
> changed.
>               >
>               >                     Section:        7.2.6
>               >                     Category:       Open Issue
>               >                     Issue:          The current draft text
>               > does not specify
>               > how to audit
>               >                     ephemerals at startup. This issue was
>               > identified by the
>               > IETF editor but has
>               >                     not yet been resolved (issue 1). The
>               > issue is, that when
>               > you boot and have
>               >                     not yet created any ephemeral
>               > terminations, how do you
>               > know what the MG can
>               >                     do. For example, how do you know if
> the
>               > MG has say an IP
>               > interface, and ATM
>               >                     interface, an MPLS interface or a
> Frame
>               > Relay interface
>               > . If you could
>               >                     audit something, you could look at the
>               > "network" value
>               > in LocalControl.
>               >                     Discussion:             A continuation
> of
>               > the discussion
>               > that has occurred
>               >                     on the Megaco mailing list so far is
>               > needed in order to
>               > resolve the issue.
>               >
>               >                     v13 Status:     OPEN. No relevant text
>               > has been added.
>               >
>               > Tom Taylor
>               > Advisor -- IPConnect Standards
>               > E-mail: taylor@nortelnetworks.com (internally, Tom-PT
> Taylor)
>               > Phone and FAX: +1 613 736 0961
>               >
>

------_=_NextPart_001_01BF6904.684CEA00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Auditing Of Packages




        I had figured that =
AuditValue would return "packages actually invoked in properties =
set for this termination".  There's an important distinction =
between that and "properties that could be invoked for a =
termination with this name pattern" -- the latter, for instance, =
might reveal that the GW supports both ATM and RTP ephemerals using the =
same simple numeric name for each, while the AuditValue would reveal =
that this particular instantiated termination has an ATM package on =
it.
        


        The issue of =
determining MG transport capabilities and the nature of ephemeral =
terminations is not closed until we close on this one.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Thursday, January 27, 2000 3:03 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
megaco@standards.nortelnetworks.com

          Subject:       =
 RE: Auditing Of Packages

          


          The whole idea of =
auditing packages "breaks" the distinction between AuditValue =
and

          AuditCapability.=A0 =
You can make an argument that Packages should be legal in =
either,

          but there aren't =
two interesting things you can get with Packages, so we decided =
that

          they were legal in =
AuditValue, and not in AuditCapabilities.=A0 We could have decided =
the

          other way, and =
there would be no difference, the decision was arbitrary.=A0=20

          I don't think there =
is any way you can assert there is any difference between =
Package=20

          audit of a physical =
termination and package audit of a (non instantiated) ephemeral=20

          termination which =
would lead you to argue that package audit of one should be in =
AuditValue

          while package audit =
of the other should be in AuditCapability.=A0 Neither ever has

          "possible =
values" or "current values".=A0 They both indicate =
"packages implemented",

          which is neither a =
possible or a current value.

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Thursday, January 27, 2000 2:53 PM
            
            To: Rosen, Brian; megaco@standards.nortelnetworks.com
            
            Subject: RE: Auditing Of Packages
            

            
            

            


            What you're saying =
is that there is no semantic difference between AuditValue and =
AuditCapability.=A0 I hope you don't mean that.=A0 We introduced the =
distinction so we could audit separately the values actually set on a =
termination vs. the choices offered to the MGC.=A0 Packages on a =
non-existent termination fall into the latter category -- they haven't =
been set yet.=A0 The whole point of the naming pattern and the W- =
wildcarding was so you could walk through and determine what the MG =
could do on an aggregate basis before you really got into call =
processing.
            


                    -----Original Message-----
            
            From:=A0=A0 Rosen, Brian =
[SMTP:brosen@fore.com]
            
            Sent:=A0=A0 Thursday, January =
27, 2000 1:13 PM
            
            To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Auditing Of =
Packages 

            


                    You are arguing the unarguable.=A0 If they =
don't exist, then you could assert that you
            
            can't do any =
kind of audit.=A0 If you want to allow an audit, then whether you =
allow
            
            auditValue or =
AuditCapability doesn't matter a whit.=A0 In this case, I'd just allow =
it
            
            for AuditValue, =
and not mess up AuditCapability.
            
=A0
            
            Brian 

            

              

                      -----Original Message-----
              
              From: Tom-PT Taylor [ <mailto:taylor@nortelnetworks.c=
om>]
              
              Sent: Thursday, January 27, 2000 12:39 PM
              
              To: MEGACO@standards.nortelnetworks.com
              
              Subject: Re: Auditing Of Packages
              

              
              

              


                      You miss the point.=A0 When an MG first starts =
up, there are no instantiated ephemeral terminations.=A0 As a result, =
you can't do an AuditValue on them.=A0 It HAS to be =
AuditCapability.
              


                      =A0=A0=A0=A0=A0=A0=A0 -----Original Message-----
              
From:=A0=A0 Rosen, Brian =
[SMTP:brosen@fore.com]
              
Sent:=A0=A0 Thursday, January =
27, 2000 10:03 AM
              
To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
              
Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Auditing Of =
Packages 

              


                      =A0=A0=A0=A0=A0=A0=A0 The Audit Descriptor has DigitMap as one of its =
options,
              
so you can ask for a DigitMap.=A0 The =
text says "DigitMap applied to the root
              
Termination returns all named DigitMaps =
in the gateway."
              
So I AuditValue does what you =
want. 

              


                      =A0=A0=A0=A0=A0=A0=A0 AuditCapability of DigitMap doesn't make any sense I =
think, and that is what
              
the text says. 

              


                      =A0=A0=A0=A0=A0=A0=A0 Packages for ephemerals are solved by name patterns, =
which was
              
what started me out on that in the first =
place.=A0 If you wildcard
              
auditValue a name pattern that equates to =
an ephemeral, and ask
              
for Packages, I think you get a list of =
packages that ephemeral
              
would support. 

              


                      =A0=A0=A0=A0=A0=A0=A0 So:
              
if =
Context=3D-{Modify=3DRoot{TerminationState{g/PatternNum=3D2}}}
might return
              
.....TerminationState(g/MaxPatterns=3D4,g/PatternNum=3D2,=
g/Pattern=3D"Ephem?n?n?n?
              
n",....}}}} 

              


                      =A0=A0=A0=A0=A0=A0=A0 then
              
Context=3D-{W-AuditValue=3DEphem*{Audit{Packages}}} 

              


                      =A0=A0=A0=A0=A0=A0=A0 should return the list of packages. 

              


                      =A0=A0=A0=A0=A0=A0=A0 While we could ask that this be made more explicit in =
the text,
              
no substantive change is warranted, I =
believe.=A0 

              


                      =A0=A0=A0=A0=A0=A0=A0 Brian 

              

              

              


                      =A0=A0=A0=A0=A0=A0=A0 > -----Original Message-----
              
> From: Tom-PT Taylor [ < <mailto:taylor@nortelnetworks.c=
om>>]
              
> Sent: Wednesday, January 26, 2000 =
9:23 PM
              
> To: =
MEGACO@standards.nortelnetworks.com
              
> Subject: Auditing Of =
Packages
              
>
              
>
              
> Every termination should support =
digit map capability, so
              
> digit map names
              
> and values are all you would want to =
audit.=A0 AuditValue is
              
> logical for that.
              
> This leaves packages, which happen =
to be tied into what types
              
> of ephemeral
              
> termination an MG will support.=A0 =
Doctrine coming out of
              
> Washington was that
              
> you would find out the latter by =
digging out the termination
              
> naming pattern,
              
> then walking through=A0 the naming =
tree to determine the capabilities
              
> supported by each branch.=A0 As Chip =
points out immediately
              
> below, however,
              
> you cannot currently determine the =
packages supported by a
              
> termination until
              
> it has been instantiated.=A0 It =
seems reasonable that
              
> AuditCapability also
              
> return a PackageList, the packages =
potentially supported by
              
> the termination
              
> as opposed to those actually =
invoked.
              
>
              
>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 From:=A0=A0=A0=A0=A0=A0=A0=A0 Chip Sharp =
<chsharp@CISCO.COM>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Subject:=A0=A0=A0=A0=A0 Auditing
              
>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6, last line
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Technical
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The draft text =
specifies
              
> that "DigitMap
              
> and Packages are
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not legal in AuditCapability". This is
              
> inconsistent with
              
> the return
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 parameters shown for the example API.
              
> Furthermore, it
              
> would seem reasonable
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 to be able determine what packages a
              
> termination (or
              
> gateway) supports as
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 well as whether digit map is supported or
              
> not. Although
              
> packages can be
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audited with AuditValue, it would seem to
              
> make more
              
> sense to allow it in
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 AuditCapability.
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Proposal:=A0=A0=A0=A0=A0=A0 It is proposed to strike the =
above
              
> sentence and allow for
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 auditing of these two capabilities.
              
>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text =
changed.
              
>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 7.2.6
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Category:=A0=A0=A0=A0=A0=A0 Open Issue
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The current draft =
text
              
> does not specify
              
> how to audit
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 ephemerals at startup. This issue was
              
> identified by the
              
> IETF editor but has
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet been resolved (issue 1). The
              
> issue is, that when
              
> you boot and have
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 not yet created any ephemeral
              
> terminations, how do you
              
> know what the MG can
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 do. For example, how do you know if the
              
> MG has say an IP
              
> interface, and ATM
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 interface, an MPLS interface or a Frame
              
> Relay interface
              
> . If you could
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 audit something, you could look at the
              
> "network" value
              
> in LocalControl.
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Discussion:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A continuation =
of
              
> the discussion
              
> that has occurred
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 on the Megaco mailing list so far is
              
> needed in order to
              
> resolve the issue.
              
>
              
>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text
              
> has been added.
              
>
              
> Tom Taylor
              
> Advisor -- IPConnect =
Standards
              
> E-mail: taylor@nortelnetworks.com =
(internally, Tom-PT Taylor)
              
> Phone and FAX: +1 613 736 =
0961
              
> 

              

        


------_=_NextPart_001_01BF6904.684CEA00--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:37:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14258
	for ; Thu, 27 Jan 2000 15:37:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04CD9920@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:34:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11771 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:33:25 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D9FD83E0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:33:25 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:34:05 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:33:48 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:33:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6905.CE3AEA46"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:33:25 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG16: CommandError in Annex A of H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6905.CE3AEA46
Content-Type: text/plain

We should probably review the whole collection of places in which the ASN.1
and ABNF show errorDescriptors -- it seems like there are a lot of them.  I
can't find "CommandError" in Annex A of the version submitted to the ITU
(shortly to be placed on the Megaco site), but that may be a
misunderstanding.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 9:16 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG16: CommandError in Annex A of H.248
>
> In Annex A, the following term "CommandError" is defined, however, it is
> not
> tied to any transaction, action, or command.  It is not clear what its use
> is.
> H.248 should state what its relationship is to the other aspects of the
> protocol
> or should remove it.
>
> It is proposed that the CommandError description in Annex A be removed.
>
> Section 3.6 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides a proposal for clarifying this issue.
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF6905.CE3AEA46
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG16: CommandError in Annex A of H.248




        We should probably =
review the whole collection of places in which the ASN.1 and ABNF show =
errorDescriptors -- it seems like there are a lot of them.  I =
can't find "CommandError" in Annex A of the version submitted =
to the ITU (shortly to be placed on the Megaco site), but that may be a =
misunderstanding.
        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 9:16 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG16: CommandError in =
Annex A of H.248

          


          In Annex A, the following term =
"CommandError" is defined, however, it is not

          tied to any transaction, action, or =
command.  It is not clear what its use is.

          H.248 should state what its =
relationship is to the other aspects of the protocol

          or should remove it.

          


          It is proposed that the CommandError =
description in Annex A be removed.

          


          Section 3.6 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides a proposal for clarifying =
this issue.

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF6905.CE3AEA46--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:37:18 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14268
	for ; Thu, 27 Jan 2000 15:37:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05152970@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:34:37 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11776 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:33:26 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DA2D1F60@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:33:25 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:34:52 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:34:31 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:34:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6905.E8F0C28E"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:34:20 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Comments on 7.1.13 on DigitMaps in H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6905.E8F0C28E
Content-Type: text/plain

Good point.  Let it be done.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 9:07 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Comments on 7.1.13 on DigitMaps in H.248
>
> Section 7.1.13 on Digit Maps needs to take into account one additional
> case.
> The case where a received digit string matches a complete string in the
> digit
> map, but also matches part of a longer string in the digit map.  This case
> requires the use of critical (or short) inter-digit timing to determine
> whether
> any further digits are required.  In this case, the short timer could be
> used
> monitor for additional digits.
>
> Steps 3 and 4 require clarification to address this issue.
>
>
> It is proposed that items 3 and 4 be replaced with the following:
> 3.   If the result does not match any entry and is under-qualified
> (partially
> matches at least one entry in the DigitMap), do nothing further.
> 4.   If the result is a match and is under-qualified (partially matches at
> least
> one other entry in the DigitMap), apply the short timer and await further
> digits. If the timer expires and no digits are received or an
> end-of-dialing
> indication is received, send the current dial string to the MGC.  If one
> or more
> digits are received apply steps 1 through 5 again.
> 5.   If the result is a match and is over-qualified (i.e., no further
> digits
> could possibly produce a match), send the current dial string to the MGC.
>
> Section 3.3 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides a proposal for resolving this issue.
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF6905.E8F0C28E
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Comments on 7.1.13 on DigitMaps in =
H.248




        Good point.  =
Let it be done.

        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 9:07 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Comments on 7.1.13 =
on DigitMaps in H.248

          


          Section 7.1.13 on Digit Maps needs to =
take into account one additional case.

          The case where a received digit =
string matches a complete string in the digit

          map, but also matches part of a =
longer string in the digit map.  This case

          requires the use of critical (or =
short) inter-digit timing to determine whether

          any further digits are =
required.  In this case, the short timer could be used

          monitor for additional digits.

          


          Steps 3 and 4 require clarification to =
address this issue.

          

          


          It is proposed that items 3 and 4 be =
replaced with the following:

          3.   If the result does not =
match any entry and is under-qualified (partially

          matches at least one entry in the =
DigitMap), do nothing further.

          4.   If the result is a =
match and is under-qualified (partially matches at least

          one other entry in the DigitMap), =
apply the short timer and await further

          digits. If the timer expires and no =
digits are received or an end-of-dialing

          indication is received, send the =
current dial string to the MGC.  If one or more

          digits are received apply steps 1 =
through 5 again.

          5.   If the result is a =
match and is over-qualified (i.e., no further digits

          could possibly produce a match), send =
the current dial string to the MGC.

          


          Section 3.3 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides a proposal for resolving =
this issue.

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF6905.E8F0C28E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:39:34 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14346
	for ; Thu, 27 Jan 2000 15:39:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4DA44BD0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:36:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11793 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:36:32 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.49651B80@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:36:32 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:38:16 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:38:08 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:38:07 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6906.6A70DD08"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:38:02 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Updates to References Section of H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6906.6A70DD08
Content-Type: text/plain

Agreed.  Not sure why SG 16 is doing this to themselves, but Annex C is
their business.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 8:52 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Updates to References Section of H.248
>
>
>
>
>
>
> The documents referenced in Annex C of H.248 (e.g., Q.763) should be added
> as
> normative references as they are needed to implement the protocol.
>
> Specifically, the following should be added as normative references since
> they
> are needed to implement the protocol of Annex C:
>
> Q.1901  (informally known as Q.BICC)
>
> Q.763-1999  (ISUP)
>
> Q.2630  (AAL2 Signaling)
>
> Q.2931  (B-ISDN Network Access Layer Signaling)
>
> Q.2941.3  (Generic Identifier Transport
> ? Extensions for BICC)
>
> Q.931-1998 (N-ISDN Network Access Layer Signaling)
>
> In addition, the reference to Q.931 in the Informative References section
> should
> be removed since it is being added to the Normative references section.
>
>
> Section 3.1 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides a proposal for updating the references.
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com
>
>

------_=_NextPart_001_01BF6906.6A70DD08
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Updates to References Section of =
H.248




        Agreed.  Not =
sure why SG 16 is doing this to themselves, but Annex C is their =
business.

        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 8:52 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Updates to =
References Section of H.248

          

          

          

          

          

          


          The documents referenced in Annex C of =
H.248 (e.g., Q.763) should be added as

          normative references as they are =
needed to implement the protocol.

          


          Specifically, the following should be =
added as normative references since they

          are needed to implement the protocol =
of Annex C:

          


          Q.1901  (informally known as =
Q.BICC)

          


          Q.763-1999  (ISUP)

          


          Q.2630  (AAL2 Signaling)

          


          Q.2931  (B-ISDN Network Access =
Layer Signaling)

          


          Q.2941.3  (Generic Identifier =
Transport

          ? Extensions for BICC)

          


          Q.931-1998 (N-ISDN Network Access =
Layer Signaling)

          


          In addition, the reference to Q.931 in =
the Informative References section should

          be removed since it is being added to =
the Normative references section.

          

          


          Section 3.1 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides a proposal for updating the =
references.

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

          

        


------_=_NextPart_001_01BF6906.6A70DD08--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:44:03 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14432
	for ; Thu, 27 Jan 2000 15:44:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01715950@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:41:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11821 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:40:56 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E6D0F150@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:40:56 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:42:06 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:41:54 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:41:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6906.F0E2F830"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:41:46 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG16: Comments on 8.1.2 regarding ContextIDs in H.2
              48
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6906.F0E2F830
Content-Type: text/plain

I think "unspecified" is out.  Current version has just one instance left --
in the sentence before the table in section 7.2.5.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 9:14 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG16: Comments on 8.1.2 regarding ContextIDs in
> H.248
>
>
>
>
>
> Section 8.1.2 of H.248 (White Paper, Megaco Version 12) describes uses for
> only
> two of the possible values for contextID: "null
> ? and "unspecified".  Actually,
> the protocol [either ASN.1 or ABNF] does not make reference to the use of
> these
> values.  It simply indicates how these are coded.  Clear requirements or
> guidelines are needed for how each of these is to be used.  For example,
> how is
> the "choose" value to be used and how/why is it different than using the
> "unspecified" value? Notice that  the "choose" wildcard is used for
> TerminationIDs to request the MG to allocate a TerminationID in the case
> of an
> ephemeral termination.
>
> Since TerminationIDs use a value of "choose" to request the MG to allocate
> a
> value in the case of an ephemeral termination (i.e., one that does not
> exist),
> contextIDs should also use the value of "choose" when requesting the MG to
> allocate a value. Section 8.1.2 should be modified so that the word
> "unspecified" is replaced with the word "choose".
>
> Section 3.5 of a Telcordia Technologies contribution to SG 16 (which can
> be
> found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC )
> provides a proposal for clarifying this issue.
>

------_=_NextPart_001_01BF6906.F0E2F830
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG16: Comments on 8.1.2 regarding ContextIDs in =
H.248




        I think =
"unspecified" is out.  Current version has just one =
instance left -- in the sentence before the table in section =
7.2.5.
        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 9:14 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG16: Comments on 8.1.2 =
regarding ContextIDs in H.248

          

          

          

          

          


          Section 8.1.2 of H.248 (White Paper, =
Megaco Version 12) describes uses for only

          two of the possible values for =
contextID: "null

          ? and "unspecified".  =
Actually,

          the protocol [either ASN.1 or ABNF] =
does not make reference to the use of these

          values.  It simply indicates how =
these are coded.  Clear requirements or

          guidelines are needed for how each of =
these is to be used.  For example, how is

          the "choose" value to be =
used and how/why is it different than using the

          "unspecified" value? Notice =
that  the "choose" wildcard is used for

          TerminationIDs to request the MG to =
allocate a TerminationID in the case of an

          ephemeral termination.

          


          Since TerminationIDs use a value of =
"choose" to request the MG to allocate a

          value in the case of an ephemeral =
termination (i.e., one that does not exist),

          contextIDs should also use the value =
of "choose" when requesting the MG to

          allocate a value. Section 8.1.2 =
should be modified so that the word

          "unspecified" is replaced =
with the word "choose".

          


          Section 3.5 of a Telcordia =
Technologies contribution to SG 16 (which can be

          found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC =
)

          provides a proposal for clarifying =
this issue.

          

        


------_=_NextPart_001_01BF6906.F0E2F830--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:46:13 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14480
	for ; Thu, 27 Jan 2000 15:46:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.493ABAB0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:43:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11827 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:42:04 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0F56A160@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:42:04 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:43:40 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 15:43:22
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 14:43:21 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6907.248B1348"
Message-ID:  
Date:         Thu, 27 Jan 2000 14:43:12 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Need to support the playing of announcements
              in H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6907.248B1348
Content-Type: text/plain

I also note that the Nortel Announcement Server package proposal has been
submitted to the SG 16 meeting.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 8:45 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Need to support the playing of
> announcements in H.248
>
> In the PSTN today, certain error conditions warrant the provision of an
> announcement to the calling user.  When the error condition occurs in a
> Voice
> over Packet (VoP) network, the VOP network needs to be able to provide the
> announcement.  In order to provide the desired announcement, the MGC needs
> to
> signal to the MG or the Announcements Server the announcement to be
> played.  It
> is desirable not to standardize the specific announcements themselves as
> network
> operators will need flexibility depending on local conditions for the
> announcement to be provided.  However, what can be standardized is the
> label
> that identifies an announcement is to be played.  An announcement
> identifier
> with a generic announcement description and possibly a field to indicate
> the
> number of cycles the announcements are to be played.
>
> Annex E.12 (Announcement) appears to be missing from the White Paper
> (MegacoH248
> Version 12).  A Telcordia Technologies contribution to SG 16 (which can be
> found
> at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-announcements.D
> OC
> ) provides some proposals to address this issue.  Specifically, Section
> 3.1 of
> this contribution proposes a set of standardized announcements/situations.
> Section 3.2 of this contribution proposes a set of announcement
> identifiers that
> could be standardized, while the corresponding announcements are
> network-specific.
>
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF6907.248B1348
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Need to support the playing of =
announcements in H.248




        I also note that the =
Nortel Announcement Server package proposal has been submitted to the =
SG 16 meeting.

        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 8:45 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Need to support the =
playing of announcements in H.248

          


          In the PSTN today, certain error =
conditions warrant the provision of an

          announcement to the calling =
user.  When the error condition occurs in a Voice

          over Packet (VoP) network, the VOP =
network needs to be able to provide the

          announcement.  In order to =
provide the desired announcement, the MGC needs to

          signal to the MG or the Announcements =
Server the announcement to be played.  It

          is desirable not to standardize the =
specific announcements themselves as network

          operators will need flexibility =
depending on local conditions for the

          announcement to be provided.  =
However, what can be standardized is the label

          that identifies an announcement is to =
be played.  An announcement identifier

          with a generic announcement =
description and possibly a field to indicate the

          number of cycles the announcements =
are to be played.

          


          Annex E.12 (Announcement) appears to =
be missing from the White Paper (MegacoH248

          Version 12).  A Telcordia =
Technologies contribution to SG 16 (which can be found

          at ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-announcements.DOC

          ) provides some proposals to address =
this issue.  Specifically, Section 3.1 of

          this contribution proposes a set of =
standardized announcements/situations.

          Section 3.2 of this contribution =
proposes a set of announcement identifiers that

          could be standardized, while the =
corresponding announcements are

          network-specific.

          

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF6907.248B1348--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:48:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14559
	for ; Thu, 27 Jan 2000 15:48:14 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91F72EA0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:45:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11845 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:45:16 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.81BDE470@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:45:16 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:46:24 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 15:46:11
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 14:46:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6907.8A9DC068"
Message-ID:  
Date:         Thu, 27 Jan 2000 14:45:54 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Essential Tones Missing from H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6907.8A9DC068
Content-Type: text/plain

These are candidates for additional region-specific or application-specific
packages.  The core set of tones are the ones recognized internationally as
evidenced by their inclusion in Rec. E.180.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Thursday, January 27, 2000 8:32 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Telcordia SG 16: Essential Tones Missing from H.248
>
>
>
>
> The version of H.248 prior to the White Paper included a list of tones
> that
> could be identified by the MGC to the MG.
>
> The White paper (Megaco Version 12 and 13) only lists a minor subset of
> these
> tones.  It is important to allow as many of the currently used tones to be
> identified as possible.
>
> Two important tones missing from this list include: recall dial tone and
> stutter
> dial tone.  Recall Dial tone is used in North American networks to provide
> an
> indication that the caller should provide more information (e.g., user has
> dialed a service access code, but has not provided a called number).
> Stutter
> dial tone is used to indicate that messages are waiting for the user for
> the
> Message Service Application.  These tones are widely used in North America
> and
> it is essential that these be included within H.248.
>
> Barge-In Tone, Incoming Additional Call Tone, Priority Additional Call
> Tone, and
> Expensive Route Warning Tone are required for Centrex type applications.
> For
> these tones a Centrex Tone Package is proposed.
>
> Barge-In Tone indicates to a party on a call that another user has bridged
> onto
> their call (e.g., supervisor observing telemarketer).  Additional Call
> Tone is
> used to inform a user that another call, which is from outside of the
> user?s
> Centrex, is waiting for the user.  Priority Additional Call Tone is used
> to
> indicate to the user that a priority call (typically) another Centrex user
> is
> waiting for them.  This last tone is used for example by a boss to
> interrupt the
> conversation of an employee.  Expensive Route Warning Tone is used when a
> route
> designated as expensive is selected for a call, which affords the caller
> with
> the opportunity to abandon the call.
>
> The specifics for these tones are provided in Section 3 of a Telcordia
> Technologies contribution to SG 16 (which can be found at
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-tones.DOC ).
>
>
> -Selvam Rengasami
> Telcordia Technologies
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com

------_=_NextPart_001_01BF6907.8A9DC068
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Essential Tones Missing from H.248




        These are candidates =
for additional region-specific or application-specific packages.  =
The core set of tones are the ones recognized internationally as =
evidenced by their inclusion in Rec. E.180.
        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Thursday, January 27, 2000 8:32 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Telcordia SG 16: Essential Tones =
Missing from H.248

          

          

          

          


          The version of H.248 prior to the =
White Paper included a list of tones that

          could be identified by the MGC to the =
MG.

          


          The White paper (Megaco Version 12 and =
13) only lists a minor subset of these

          tones.  It is important to allow =
as many of the currently used tones to be

          identified as possible.

          


          Two important tones missing from this =
list include: recall dial tone and stutter

          dial tone.  Recall Dial tone is =
used in North American networks to provide an

          indication that the caller should =
provide more information (e.g., user has

          dialed a service access code, but has =
not provided a called number).  Stutter

          dial tone is used to indicate that =
messages are waiting for the user for the

          Message Service Application.  =
These tones are widely used in North America and

          it is essential that these be =
included within H.248.

          


          Barge-In Tone, Incoming Additional =
Call Tone, Priority Additional Call Tone, and

          Expensive Route Warning Tone are =
required for Centrex type applications.  For

          these tones a Centrex Tone Package is =
proposed.

          


          Barge-In Tone indicates to a party on =
a call that another user has bridged onto

          their call (e.g., supervisor =
observing telemarketer).  Additional Call Tone is

          used to inform a user that another =
call, which is from outside of the user?s

          Centrex, is waiting for the =
user.  Priority Additional Call Tone is used to

          indicate to the user that a priority =
call (typically) another Centrex user is

          waiting for them.  This last =
tone is used for example by a boss to interrupt the

          conversation of an employee.  =
Expensive Route Warning Tone is used when a route

          designated as expensive is selected =
for a call, which affords the caller with

          the opportunity to abandon the =
call.

          


          The specifics for these tones are =
provided in Section 3 of a Telcordia

          Technologies contribution to SG 16 =
(which can be found at

          ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-tones.DOC ).

          

          


          -Selvam Rengasami

          Telcordia Technologies

          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

        


------_=_NextPart_001_01BF6907.8A9DC068--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 15:58:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14698
	for ; Thu, 27 Jan 2000 15:58:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8BD30C0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:55:45 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11872 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:54:16 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C3B59930@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:54:16 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:53:13 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:52:54 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:52:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6908.6DAF8EE0"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:52:29 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6908.6DAF8EE0
Content-Type: text/plain

Brian has stated this very clearly, but I'll head off one small doubt.  If
the MGC issues a ServiceChange (restart) for the the termination and it can
be recovered (i.e. hasn't lost its bearer), the MG should act on the
command.  If the termination cannot be recovered the MG should reject the
command with error return.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Thursday, January 27, 2000 10:52 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: ServiceChange
>
> I believe the MG should do what the MGC says.
>
> The MGC is responsible for making the state consistent, and this
> means getting the Subtract through.
>
> A termination could be out of service, but still in a context,
> and would be under failure conditions.  The MGC must run the
> Subtract command to get the state reasonable.
>
> If a command other than Subtract (or ServiceChange) was received on a
> termination that is out of service, an error should be returned.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu [mailto:bmbabu@hss.hns.com]
> > Sent: Thursday, January 27, 2000 5:00 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: ServiceChange
> >
> >
> > When a termination is marked out-of-service through
> > ServiceChange command
> > using graceful/ forced ServiceChangeMethod, and MGC has not
> > yet sent Subtract
> > command for that termination, what is the processing
> > associated at MG when
> > second
> > ServiceChange command arrives with Restart method. Should it
> > be removed from
> > context or disallow second ServiceChange command?
> >
> > There is no text in Version 13  mentioning that when
> > terminations are brought
> > back
> > to service using Restart ServiceChange command, what the
> > context of the
> > terminations
> > will be. Version 11 did mention this as "the Termiantions are
> > assumed to now not
> > be
> > associated with any Context".
> >

------_=_NextPart_001_01BF6908.6DAF8EE0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: ServiceChange




        Brian has stated =
this very clearly, but I'll head off one small doubt.  If the MGC =
issues a ServiceChange (restart) for the the termination and it can be =
recovered (i.e. hasn't lost its bearer), the MG should act on the =
command.  If the termination cannot be recovered the MG should =
reject the command with error return.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Thursday, January 27, 2000 10:52 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: ServiceChange

          


          I believe the MG should do what the =
MGC says.

          


          The MGC is responsible for making the =
state consistent, and this

          means getting the Subtract =
through.

          


          A termination could be out of service, =
but still in a context,

          and would be under failure =
conditions.  The MGC must run the

          Subtract command to get the state =
reasonable.

          


          If a command other than Subtract (or =
ServiceChange) was received on a

          termination that is out of service, =
an error should be returned.

          


          Brian

          


          > -----Original Message-----

          > From: Madhu Babu =
[mailto:bmbabu@hss.hns.com<=
/U>]

          > Sent: Thursday, January 27, 2000 =
5:00 AM

          > To: =
MEGACO@standards.nortelnetworks.com

          > Subject: ServiceChange

          >

          >

          > When a termination is marked =
out-of-service through

          > ServiceChange command

          > using graceful/ forced =
ServiceChangeMethod, and MGC has not

          > yet sent Subtract

          > command for that termination, =
what is the processing

          > associated at MG when

          > second

          > ServiceChange command arrives =
with Restart method. Should it

          > be removed from

          > context or disallow second =
ServiceChange command?

          >

          > There is no text in Version =
13  mentioning that when

          > terminations are brought

          > back

          > to service using Restart =
ServiceChange command, what the

          > context of the

          > terminations

          > will be. Version 11 did mention =
this as "the Termiantions are

          > assumed to now not

          > be

          > associated with any =
Context".

          >

          

        


------_=_NextPart_001_01BF6908.6DAF8EE0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 16:02:24 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14794
	for ; Thu, 27 Jan 2000 16:02:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.888DBFD0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:59:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11889 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:58:31 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5B863120@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:58:31 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 14:59:23 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 15:59:09 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:59:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6909.5704F2EC"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:58:57 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Importance of ContextID in ServiceChange command
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6909.5704F2EC
Content-Type: text/plain

Good point.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Thursday, January 27, 2000 4:07 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Importance of ContextID in ServiceChange command
>
> HI all
>
> It should be mentioned somewhere in the text that there is no
> siginificance of
> ContextID in case of ServiceChange Command. The ServiceChange command
> is for terminations and no validation is done on ContextID should be done.

------_=_NextPart_001_01BF6909.5704F2EC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Importance of ContextID in ServiceChange command




        Good point.

        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Thursday, January 27, 2000 4:07 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Importance of ContextID in =
ServiceChange command

          


          HI all

          


          It should be mentioned somewhere in =
the text that there is no siginificance of

          ContextID in case of ServiceChange =
Command. The ServiceChange command

          is for terminations and no validation =
is done on ContextID should be done.

          

        


------_=_NextPart_001_01BF6909.5704F2EC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 16:02:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14811
	for ; Thu, 27 Jan 2000 16:02:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8910F990@standards.nortelnetworks.com>; Thu, 27 Jan 2000 15:59:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11898 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 15:59:12 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.73E0EEE0@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          15:59:12 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 15:00:51 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Thu, 27
          Jan 2000 16:00:40 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 16:00:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6909.8A583262"
Message-ID:  
Date:         Thu, 27 Jan 2000 16:00:21 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: ServiceChange in Null context.
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6909.8A583262
Content-Type: text/plain

Another good point.  In the NULL context the state should immediately go to
"out of service".  No need to be graceful when the termination isn't
actively involved in a call.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Thursday, January 27, 2000 3:53 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ServiceChange in Null context.
>
> According to Section 7.2.8 it is mentioned that when a termination
> receives
> ServiceChange
> command with graceful ServiceChangeMethod and ServiceChangeDelay = NULL
> then
> MG should set state= "test" and INDEFINITELY wait for Subtract command.
> what is the behavior of MG when the termination is in NULL context?

------_=_NextPart_001_01BF6909.8A583262
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: ServiceChange in Null context.




        Another good =
point.  In the NULL context the state should immediately go to =
"out of service".  No need to be graceful when the =
termination isn't actively involved in a call.
        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Thursday, January 27, 2000 3:53 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 ServiceChange in Null =
context.

          


          According to Section 7.2.8 it is =
mentioned that when a termination receives

          ServiceChange

          command with graceful =
ServiceChangeMethod and ServiceChangeDelay =3D NULL then

          MG should set state=3D =
"test" and INDEFINITELY wait for Subtract command.

          what is the behavior of MG when the =
termination is in NULL context?

          

        


------_=_NextPart_001_01BF6909.8A583262--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 16:12:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14918
	for ; Thu, 27 Jan 2000 16:12:04 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFB7DAF0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:09:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11921 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 16:08:31 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C1223230@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          16:08:31 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 15:09:48 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 16:09:29
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:09:28 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF690A.CAE22170"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:09:24 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF690A.CAE22170
Content-Type: text/plain

I think one could interpret Context=${Add=${}} as follows:

"Create a new context.  Allocate a terminationID and any software resources
required to hold more information about that termination when that
information is provided.  Return an error if there is any attempt to
activate a media flow before there is enough information to do so."  Not
sure why you'd do this really -- it means extra messaging to follow up.


> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Wednesday, January 26, 2000 4:07 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Choosing of ephemeral / physical Termination.
>
> Generally determined by the "kind" of termination requested.
> Which is in turn, easily discernable from the Media command.
>
> However, upon reflection, I think it's not a good answer.
> I'd propose that we not allow selection of a physical termination,
> in which case choose is always create an ephemeral.  In particular,
> the following is perfectly legal:
> Context=${Add=${}}
> What do you get?
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > Sent: Tuesday, January 25, 2000 9:01 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Choosing of ephemeral / physical Termination.
> >
> >
> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> > to signal to the MG
> > that it has to create an
> > ephemeral Termination or select an idle physical Termination".
> > How can MG determine when to create an ephemeral termination
> > and when to choose
> > idle physical termination.??
> > What is the logic behind this decision making?
> >
> > regards
> > -Sachin Mittal
> >

------_=_NextPart_001_01BF690A.CAE22170
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Choosing of ephemeral / physical Termination.




        I think one could =
interpret Context=3D${Add=3D${}} =
as follows:

        


        "Create a new context.  =
Allocate a terminationID and any software resources required to hold =
more information about that termination when that information is =
provided.  Return an error if there is any attempt to activate a =
media flow before there is enough information to do so."  Not =
sure why you'd do this really -- it means extra messaging to follow =
up.
        

        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Wednesday, January 26, 2000 4:07 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Choosing of ephemeral / physical =
Termination.

          


          Generally determined by the =
"kind" of termination requested.

          Which is in turn, easily discernable =
from the Media command.

          


          However, upon reflection, I think it's =
not a good answer.

          I'd propose that we not allow =
selection of a physical termination,

          in which case choose is always create =
an ephemeral.  In particular,

          the following is perfectly =
legal:

          Context=3D${Add=3D${}}

          What do you get?

          


          Brian

          


          > -----Original Message-----

          > From: Sachin Mittal =
[mailto:samittal@hss.hns.com]

          > Sent: Tuesday, January 25, 2000 =
9:01 AM

          > To: =
MEGACO@standards.nortelnetworks.com

          > Subject: Choosing of ephemeral / =
physical Termination.

          >

          >

          > Annex B.1 says that "The =
CHOOSE TerminationID $ may be used

          > to signal to the MG

          > that it has to create an

          > ephemeral Termination or select =
an idle physical Termination".

          > How can MG determine when to =
create an ephemeral termination

          > and when to choose

          > idle physical =
termination.??

          > What is the logic behind this =
decision making?

          >

          > regards

          > -Sachin Mittal

          >

          

        


------_=_NextPart_001_01BF690A.CAE22170--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Jan 27 16:22:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15044
	for ; Thu, 27 Jan 2000 16:22:05 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.56E92200@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:19:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11949 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 27 Jan 2000 16:18:09 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.19897680@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          16:18:09 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 15:18:51 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 16:18:33
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:18:32 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF690C.103B46EC"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:18:28 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Comment on E.3.4
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF690C.103B46EC
Content-Type: text/plain

Agreed, except that the problem is with DTMF detection (E.6, referring back
to E.5).  In accordance with the description of digit maps in 7.1.14,
mapping should be provided between the events dd/d0 through dd/d9 and digit
map symbols "0" through "9"; between events dd/da through dd/dd and symbols
"A" through "D"; between event dd/d* (is this name legal in our ABNF??) and
symbol "E"; and between event dd/d# (another dubious name!) and symbol "F".


> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 9:14 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Comment on E.3.4
>
> Section:        E.3.4
> Category:       Editorial
> Issue:          The chosen values for signal IDs are somewhat confusing
> considering
> the fact that another representation is used in digit maps.
> Proposal:       It is recommended that, at a minimum, it should be
> clarified that
> the signal ID values specified here are translated to another
> representation prior to attempting a match in a digit map.
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF690C.103B46EC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Comment on E.3.4




        Agreed, except that =
the problem is with DTMF detection (E.6, referring back to E.5).  =
In accordance with the description of digit maps in 7.1.14, mapping =
should be provided between the events dd/d0 through dd/d9 and digit map =
symbols "0" through "9"; between events dd/da =
through dd/dd and symbols "A" through "D"; between =
event dd/d* (is this name legal in our ABNF??) and symbol =
"E"; and between event dd/d# (another dubious name!) and =
symbol "F".
        

        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

          Sent:   Tuesday, January 25, 2000 9:14 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Cisco SG16: Comment on E.3.4

          


          Section:        =
E.3.4

          Category:       =
Editorial

          Issue:        &nb=
sp; The chosen values for signal IDs are somewhat confusing

          considering

          the fact that another representation =
is used in digit maps.

          Proposal:       It is =
recommended that, at a minimum, it should be

          clarified that

          the signal ID values specified here =
are translated to another

          representation prior to attempting a =
match in a digit map.

          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF690C.103B46EC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23906
	for ; Fri, 28 Jan 2000 14:04:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A75A1D0@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11961 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:29 -0500
Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.5F9E7120@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:20:06
          -0500
Received: from zrchh190 by smtprich.nortel.com; Thu, 27 Jan 2000 15:22:23 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zrchh190; Thu, 27
          Jan 2000 15:30:49 -0600
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 16:20:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF690C.57CEB7B4"
X-Orig: 
Message-ID:  
Date:         Thu, 27 Jan 2000 16:20:29 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: ATM encoding in SDP
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

------_=_NextPart_001_01BF690C.57CEB7B4
Content-type: text/plain; charset="us-ascii"

As I remarked in a response to Selvam, we are expecting a total of three
contributions on the issue: the Nortel one (so far undiscussed), one from
the MSF, and one that David Oran told me was on the way.  I would hope with
all this that the necessary package definitions get hammered out soon.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 8:19 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: ATM encoding in SDP
>
> Section:        B
> Category:       Open Issue
> Issue:          The draft text does not specify how to support ATM bearer
> descriptions in SDP, however Annex C has syntax to create ATM bearers for
> the binary encoding. This issue was identified by the IETF editor but has
> not yet been resolved (issue 11).
> Discussion:             A continuation of the discussion that has occurred
> on the
> Megaco mailing list so far is needed in order to resolve the issue.
>
> v13 Status:     OPEN. No relevant text has changed.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF690C.57CEB7B4
Content-type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: ATM encoding in SDP




        As I remarked in a =
response to Selvam, we are expecting a total of three contributions on =
the issue: the Nortel one (so far undiscussed), one from the MSF, and =
one that David Oran told me was on the way.  I would hope with all =
this that the necessary package definitions get hammered out =
soon.
        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

          Sent:   Tuesday, January 25, 2000 8:19 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Cisco SG16: ATM encoding in =
SDP

          


          Section:        =
B

          Category:       Open =
Issue

          Issue:        &nb=
sp; The draft text does not specify how to support ATM bearer

          descriptions in SDP, however Annex C =
has syntax to create ATM bearers for

          the binary encoding. This issue was =
identified by the IETF editor but has

          not yet been resolved (issue =
11).

          Discussion:       &nbs=
p;     A continuation of the discussion that has =
occurred on the

          Megaco mailing list so far is needed =
in order to resolve the issue.

          


          v13 Status:     =
OPEN. No relevant text has changed.

          


          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF690C.57CEB7B4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23934
	for ; Fri, 28 Jan 2000 14:05:03 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AB85020@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12002 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:30 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.0EB5A240@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          16:32:09 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 15:33:08 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 16:32:46
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:32:45 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF690E.0C6F86FC"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:32:39 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Virtual MG & Root
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF690E.0C6F86FC
Content-Type: text/plain

I think this is a reasonable proposal.  When the sentence in question was
placed there, people had visions of one MGC knocking out the whole
(physical) MG.  If we simply interpret ServiceChange to be limited in scope
to the virtual MG, it allows, for instance, an MGC to shed load by handing
over responsibility for that virtual MG to another controller.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 8:08 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Virtual MG & Root
>
> Section:        11.1, second last paragraph
> Category:       Technical/Editorial
> Issue:          The draft text specifies that "Each virtual MG has its own
> Root
> Termination" but "ServiceChange may only be applied to the Root by the
> Master MGC". The two statements seem to be inconsistent as the purpose of
> the virtual MG (and thereby the root termination for that virtual MG) is
> to
> allow the MGC for the virtual MG to control that virtual MG.
> Proposal:       It is proposed, that the last sentence is removed since
> each
> virtual MG has its own Root termination.
>
> v13 Status:     OPEN. No relevant text changed.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF690E.0C6F86FC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Virtual MG & Root




        I think this is a =
reasonable proposal.  When the sentence in question was placed =
there, people had visions of one MGC knocking out the whole (physical) =
MG.  If we simply interpret ServiceChange to be limited in scope =
to the virtual MG, it allows, for instance, an MGC to shed load by =
handing over responsibility for that virtual MG to another =
controller.
        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

          Sent:   Tuesday, January 25, 2000 8:08 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Cisco SG16: Virtual MG & =
Root

          


          Section:        11.1, =
second last paragraph

          Category:       =
Technical/Editorial

          Issue:        &nb=
sp; The draft text specifies that "Each virtual MG has its own =
Root

          Termination" but =
"ServiceChange may only be applied to the Root by the

          Master MGC". The two statements =
seem to be inconsistent as the purpose of

          the virtual MG (and thereby the root =
termination for that virtual MG) is to

          allow the MGC for the virtual MG to =
control that virtual MG.

          Proposal:       It is =
proposed, that the last sentence is removed since each

          virtual MG has its own Root =
termination.

          


          v13 Status:     =
OPEN. No relevant text changed.

          


          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF690E.0C6F86FC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23951
	for ; Fri, 28 Jan 2000 14:05:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AFB2580@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12028 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:30 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.7B9C65F0@standards.nortelnetworks.com>; Thu, 27 Jan 2000 16:42:22
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          NAA02427; Thu, 27 Jan 2000 13:36:05 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000127162802.00aeba80@dogwood.cisco.com>
Date:         Thu, 27 Jan 2000 16:30:53 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: BufferedEventHandling
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

I disagreed with what I heard at the design team meeting at the meeting.
I am proposing we keep what we have had for several months before the
Washington meeting rather than replace it with a whole new mechanism.

Chip

At 12:44 PM 1/27/00 -0500, Tom-PT Taylor wrote:

>Event handling received a LOT of discussion in Washington.  The existing
>text dates from there; I can't see revisiting the issue.
>-----Original Message-----  From:   Chip Sharp
>[SMTP:chsharp@CISCO.COM]  Sent:   Tuesday, January 25, 2000 6:23
>PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
>BufferedEventHandling
>
>Section:        7.1.7  Category:       Technical, Open
>Issue  Issue:          At the end of the Red Bank meeting, Section 7.1.7
>on  LocalControlDescriptor (Section 7.1.8 in TD-58 from the Red Bank
>meeting  [3]), contained the following text: "The TerminationBuffered
>parameter  describes actions taken by the MG when events are not
>immediately notified  to the
>controller.  1.      BufferedEventProcessingMode  specifies whether
>buffered events should be  processed (Process) or discarded
>(Discard)  2.      BufferedEventNotificationMode  specifies whether the
>Media Gateway is  expected to detect the requested event and notify the
>controller once (step  by step) or repeatedly (Loop).  The white
>contribution does not contain this text which constitutes a  significant
>technical change to the operation of event detection and  notification
>which we strongly disagree with.  Discussion:             It is
>recommended that the above deleted text is added to  Section 7.1.7 again.
>
>v13 Status:     WIDE OPEN. Text still missing. Extensive modification of
>entire  event processing has taken place.
>
>Section:        7.2.7, second last paragraph  Category:       Technical,
>Open Issue  Issue:          The draft text specifies that "If the
>BufferedEventProcessingMode  parameter of the Termination is set to
>"Discard", then the list shall  contain only the event that triggered the
>notification".  This constitutes a significant technical change to the
>operation of event  detection as indicated earlier for Section 7.1.7. The
>text was not present  at the end of the Red Bank meeting [3], nor should
>it be. Furthermore, the  text does not seem to make much sense; if an
>event is not to be reported,  then it is simply not included in the
>EventsDescriptor. This relates to the  removal of the
>BufferedEventNotificationMode which should not have
>happened.  Discussion:     It is strongly recommended that the
>specification on event  buffering concerning both notification and
>processing is revisited and  brought back in line with the outcome of the
>Red Bank meeting.
>
>v13 Status:     OPEN. Although the text has been removed, it is part of
>an  extensive modification of the entire event handling mechanism.
>
>Support
>NetAid!  http://www.netaid.org
>--------------------------------------------------  Chip
>Sharp                 Consulting Engineering  Cisco
>Systems              Telco Bio-region  Reality - Love it or Leave
>it.  --------------------------------------------------

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:17 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23962
	for ; Fri, 28 Jan 2000 14:05:13 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B3DD3D0@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12052 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:30 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.B3BE6770@standards.nortelnetworks.com>; Thu, 27 Jan 2000
          16:51:05 -0500
Received: from zmers013 by smtprch1.nortel.com; Thu, 27 Jan 2000 15:52:40 -0600
Received: from zrchb213.us.nortel.com by zmers013; Thu, 27 Jan 2000 16:52:23
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Thu, 27 Jan 2000 15:52:22 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6910.CA2663D0"
Message-ID:  
Date:         Thu, 27 Jan 2000 15:52:20 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Transaction ID uniqueness
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6910.CA2663D0
Content-Type: text/plain;
        charset="iso-8859-1"

This looks reasonable.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@CISCO.COM]
> Sent: Tuesday, January 25, 2000 8:07 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Cisco SG16: Transaction ID uniqueness
>
> Section:        D.1.1, second paragraph
> Category:       Technical, Editorial
> Issue:          The draft text specifies that "The transaction identifiers
> of
> incoming messages are compared to the transaction identifiers of the
> recent
> responses". This is inconsistent with Section 8.1.1 where transaction
> identifiers are defined to only be unique within the scope of a given
> sender. Transaction identifiers should indeed be unique within the scope
> of
> a given sender to avoid having to synchronize transaction identifiers
> between MGC's, e.g. when handoff or failover is performed.
> Proposal:       It is proposed that the text is modified to be consistent
> with
> Section 8.1.1.
>
> v13 Status:     OPEN. No text changed.
>
>
        [[TomT]]  other issues snipped
>
>
> Section:        D.1.2, first paragraph, last line
> Category:       Technical, Editorial
> Issue:          The draft text specifies that "MGs can simply detect
> duplicate
> transactions by looking at the transaction identifier only". This is
> inconsistent with the "sender uniqueness only" requirement on transaction
> identifiers in Section 8.1.1, which implied that MGs have to look at the
> combination of "mId" and transaction identifier to identify a duplicate
> transaction.
>
> Proposal:       It is recommended that the text is modified to be
> consistent with
> Section 8.1.1, i.e. that the combination of transaction identifier and mId
>
> identifies a given transaction.
>
> v13 Status:     OPEN. No text changed.
>
>
        [[TomT]]  other issues snipped
>
> Section:        D.1.4, fourth paragraph
> Category:       Technical
> Issue:          The draft text specifies that "The transaction identifiers
> of
> incoming transactions are compared...". The paragraph duplicates Section
> D.1.1 and contains the same problem of ignoring the "sender uniqueness
> only" requirement on transaction identifiers as well as not issuing a
> provisional response when a duplicate request for an in-progress
> transaction.
> Proposal:       It is proposed that the paragraph is either removed or the
> text
> modified to reflect the "sender uniqueness requirement" and sending of a
> provisional response.
>
> v13 Status:     OPEN. No text changed.
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

------_=_NextPart_001_01BF6910.CA2663D0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Transaction ID uniqueness




        This looks =
reasonable.

        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@CISCO.COM]

          Sent:   Tuesday, January 25, 2000 8:07 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Cisco SG16: Transaction ID =
uniqueness

          


          Section:        =
D.1.1, second paragraph

          Category:       Technical, =
Editorial

          Issue:        &nb=
sp; The draft text specifies that "The transaction identifiers of =


          incoming messages are compared to the =
transaction identifiers of the recent 

          responses". This is inconsistent with =
Section 8.1.1 where transaction 

          identifiers are defined to only be =
unique within the scope of a given 

          sender. Transaction identifiers =
should indeed be unique within the scope of 

          a given sender to avoid having to =
synchronize transaction identifiers 

          between MGC's, e.g. when handoff or =
failover is performed.

          Proposal:       It is =
proposed that the text is modified to be consistent with 

          Section 8.1.1.

          


          v13 Status:     =
OPEN. No text changed.

          

          


          [[TomT]]  other issues snipped

           

          


          Section:        =
D.1.2, first paragraph, last line

          Category:       Technical, =
Editorial

          Issue:        &nb=
sp; The draft text specifies that "MGs can simply detect duplicate =


          transactions by looking at the =
transaction identifier only". This is 

          inconsistent with the "sender =
uniqueness only" requirement on transaction 

          identifiers in Section 8.1.1, which =
implied that MGs have to look at the 

          combination of "mId" and transaction =
identifier to identify a duplicate 

          transaction.

          


          Proposal:       It is =
recommended that the text is modified to be consistent with 

          Section 8.1.1, i.e. that the =
combination of transaction identifier and mId 

          identifies a given =
transaction.

          


          v13 Status:     =
OPEN. No text changed.

          

          


          [[TomT]]  other issues snipped

           

          Section:        =
D.1.4, fourth paragraph

          Category:       =
Technical

          Issue:        &nb=
sp; The draft text specifies that "The transaction identifiers of =


          incoming transactions are =
compared...". The paragraph duplicates Section 

          D.1.1 and contains the same problem =
of ignoring the "sender uniqueness 

          only" requirement on transaction =
identifiers as well as not issuing a 

          provisional response when a duplicate =
request for an in-progress transaction.

          Proposal:       It is =
proposed that the paragraph is either removed or the text 

          modified to reflect the "sender =
uniqueness requirement" and sending of a 

          provisional response.

          


          v13 Status:     =
OPEN. No text changed.

          


          Support NetAid!  =
http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave =
it.          =
        

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF6910.CA2663D0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:23 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23972
	for ; Fri, 28 Jan 2000 14:05:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B80A930@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12297 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:31 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4E1F1C20@standards.nortelnetworks.com>; Thu, 27 Jan 2000 22:10:22
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA29350; Fri, 28 Jan
          2000 09:04:36 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256874.00107BF2 ; Fri, 28 Jan 2000 08:30:03 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=MJH5EQW4S9tflyorjYpX2h0apoFVN3EHik4XkDwSzZZ1Hs49enyFT7QP"
Content-Disposition: inline
Message-ID:  <65256874.00107BBF.00@sandesh.hss.hns.com>
Date:         Fri, 28 Jan 2000 08:33:28 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Madhu Babu 
Subject:      Re: ServiceChange
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=MJH5EQW4S9tflyorjYpX2h0apoFVN3EHik4XkDwSzZZ1Hs49enyFT7QP
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



This sounds good. This implies that when terminations are taken out-of-service
the descriptors present at MG will be having values prior to receiving/sending
ServiceChange.

This implies that when a termination is out-of-service, its the responsiblity of
MGC to
update the descriptors at MG ( SInce the termination have gone out-of-service
when the termination is either in context. or NULL context).




Tom-PT Taylor  on 01/28/2000 02:22:29 AM

Please respond to Tom-PT Taylor 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Madhu B Babu/HSS)

Subject:  Re: ServiceChange




Brian has stated this very clearly, but I'll head off one small doubt.  If
the MGC issues a ServiceChange (restart) for the the termination and it can
be recovered (i.e. hasn't lost its bearer), the MG should act on the
command.  If the termination cannot be recovered the MG should reject the
command with error return.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Thursday, January 27, 2000 10:52 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: ServiceChange
>
> I believe the MG should do what the MGC says.
>
> The MGC is responsible for making the state consistent, and this
> means getting the Subtract through.
>
> A termination could be out of service, but still in a context,
> and would be under failure conditions.  The MGC must run the
> Subtract command to get the state reasonable.
>
> If a command other than Subtract (or ServiceChange) was received on a
> termination that is out of service, an error should be returned.
>
> Brian
>
> > -----Original Message-----
> > From: Madhu Babu [mailto:bmbabu@hss.hns.com]
> > Sent: Thursday, January 27, 2000 5:00 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: ServiceChange
> >
> >
> > When a termination is marked out-of-service through
> > ServiceChange command
> > using graceful/ forced ServiceChangeMethod, and MGC has not
> > yet sent Subtract
> > command for that termination, what is the processing
> > associated at MG when
> > second
> > ServiceChange command arrives with Restart method. Should it
> > be removed from
> > context or disallow second ServiceChange command?
> >
> > There is no text in Version 13  mentioning that when
> > terminations are brought
> > back
> > to service using Restart ServiceChange command, what the
> > context of the
> > terminations
> > will be. Version 11 did mention this as "the Termiantions are
> > assumed to now not
> > be
> > associated with any Context".
> >


--0__=MJH5EQW4S9tflyorjYpX2h0apoFVN3EHik4XkDwSzZZ1Hs49enyFT7QP
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI0NDguMCI+DQo8VElUTEU+UkU6IFNlcnZp
Y2VDaGFuZ2U8L1RJVExFPg0KPC9IRUFEPg0KPEJPRFk+DQoNCjxQPjxGT05UIENPTE9SPSIjMDAw
MEZGIiBTSVpFPTIgRkFDRT0iQXJpYWwiPkJyaWFuIGhhcyBzdGF0ZWQgdGhpcyB2ZXJ5IGNsZWFy
bHksIGJ1dCBJJ2xsIGhlYWQgb2ZmIG9uZSBzbWFsbCBkb3VidC4mbmJzcDsgSWYgdGhlIE1HQyBp
c3N1ZXMgYSBTZXJ2aWNlQ2hhbmdlIChyZXN0YXJ0KSBmb3IgdGhlIHRoZSB0ZXJtaW5hdGlvbiBh
bmQgaXQgY2FuIGJlIHJlY292ZXJlZCAoaS5lLiBoYXNuJ3QgbG9zdCBpdHMgYmVhcmVyKSwgdGhl
IE1HIHNob3VsZCBhY3Qgb24gdGhlIGNvbW1hbmQuJm5ic3A7IElmIHRoZSB0ZXJtaW5hdGlvbiBj
YW5ub3QgYmUgcmVjb3ZlcmVkIHRoZSBNRyBzaG91bGQgcmVqZWN0IHRoZSBjb21tYW5kIHdpdGgg
ZXJyb3IgcmV0dXJuLjwvRk9OVD48L1A+DQo8VUw+DQo8UD48Rk9OVCBTSVpFPTEgRkFDRT0iQXJp
YWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9
MSBGQUNFPSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEg
RkFDRT0iQXJpYWwiPlJvc2VuLCBCcmlhbiBbU01UUDpicm9zZW5ARk9SRS5DT01dPC9GT05UPg0K
PEJSPjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U2VudDombmJzcDsmbmJzcDs8L0ZPTlQ+
PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDAw
IDEwOjUyIEFNPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+VG86Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFs
Ij5NRUdBQ09AU1RBTkRBUkRTLk5PUlRFTE5FVFdPUktTLkNPTTwvRk9OVD4NCjxCUj48Qj48Rk9O
VCBTSVpFPTEgRkFDRT0iQXJpYWwiPlN1YmplY3Q6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvQj4gPEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5SZTog
U2VydmljZUNoYW5nZTwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij5JIGJlbGlldmUgdGhlIE1HIHNob3VsZCBkbyB3aGF0IHRoZSBNR0Mgc2F5cy48L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+VGhlIE1HQyBpcyByZXNwb25zaWJs
ZSBmb3IgbWFraW5nIHRoZSBzdGF0ZSBjb25zaXN0ZW50LCBhbmQgdGhpczwvRk9OVD4NCjxCUj48
Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPm1lYW5zIGdldHRpbmcgdGhlIFN1YnRyYWN0IHRocm91
Z2guPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPkEgdGVybWlu
YXRpb24gY291bGQgYmUgb3V0IG9mIHNlcnZpY2UsIGJ1dCBzdGlsbCBpbiBhIGNvbnRleHQsPC9G
T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YW5kIHdvdWxkIGJlIHVuZGVyIGZh
aWx1cmUgY29uZGl0aW9ucy4mbmJzcDsgVGhlIE1HQyBtdXN0IHJ1biB0aGU8L0ZPTlQ+DQo8QlI+
PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5TdWJ0cmFjdCBjb21tYW5kIHRvIGdldCB0aGUgc3Rh
dGUgcmVhc29uYWJsZS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlh
bCI+SWYgYSBjb21tYW5kIG90aGVyIHRoYW4gU3VidHJhY3QgKG9yIFNlcnZpY2VDaGFuZ2UpIHdh
cyByZWNlaXZlZCBvbiBhPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+dGVy
bWluYXRpb24gdGhhdCBpcyBvdXQgb2Ygc2VydmljZSwgYW4gZXJyb3Igc2hvdWxkIGJlIHJldHVy
bmVkLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5Ccmlhbjwv
Rk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+
Jmd0OyBGcm9tOiBNYWRodSBCYWJ1IFs8VT48L1U+PC9GT05UPjxVPjxGT05UIENPTE9SPSIjMDAw
MEZGIiBTSVpFPTIgRkFDRT0iQXJpYWwiPjxBIEhSRUY9Im1haWx0bzpibWJhYnVAaHNzLmhucy5j
b20iPm1haWx0bzpibWJhYnVAaHNzLmhucy5jb208L0E+PC9GT05UPjwvVT48Rk9OVCBTSVpFPTIg
RkFDRT0iQXJpYWwiPl08L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7
IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDAwIDU6MDAgQU08L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IFRvOiBNRUdBQ09Ac3RhbmRhcmRzLm5vcnRlbG5l
dHdvcmtzLmNvbTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDsgU3Vi
amVjdDogU2VydmljZUNoYW5nZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi
PiZndDs8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7PC9GT05UPg0K
PEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyBXaGVuIGEgdGVybWluYXRpb24gaXMg
bWFya2VkIG91dC1vZi1zZXJ2aWNlIHRocm91Z2g8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZB
Q0U9IkFyaWFsIj4mZ3Q7IFNlcnZpY2VDaGFuZ2UgY29tbWFuZDwvRk9OVD4NCjxCUj48Rk9OVCBT
SVpFPTIgRkFDRT0iQXJpYWwiPiZndDsgdXNpbmcgZ3JhY2VmdWwvIGZvcmNlZCBTZXJ2aWNlQ2hh
bmdlTWV0aG9kLCBhbmQgTUdDIGhhcyBub3Q8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9
IkFyaWFsIj4mZ3Q7IHlldCBzZW50IFN1YnRyYWN0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBG
QUNFPSJBcmlhbCI+Jmd0OyBjb21tYW5kIGZvciB0aGF0IHRlcm1pbmF0aW9uLCB3aGF0IGlzIHRo
ZSBwcm9jZXNzaW5nPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyBh
c3NvY2lhdGVkIGF0IE1HIHdoZW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFs
Ij4mZ3Q7IHNlY29uZDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDsg
U2VydmljZUNoYW5nZSBjb21tYW5kIGFycml2ZXMgd2l0aCBSZXN0YXJ0IG1ldGhvZC4gU2hvdWxk
IGl0PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyBiZSByZW1vdmVk
IGZyb208L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IGNvbnRleHQg
b3IgZGlzYWxsb3cgc2Vjb25kIFNlcnZpY2VDaGFuZ2UgY29tbWFuZD88L0ZPTlQ+DQo8QlI+PEZP
TlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Jmd0OyBUaGVyZSBpcyBubyB0ZXh0IGluIFZlcnNpb24gMTMmbmJzcDsgbWVudGlv
bmluZyB0aGF0IHdoZW48L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7
IHRlcm1pbmF0aW9ucyBhcmUgYnJvdWdodDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0i
QXJpYWwiPiZndDsgYmFjazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZn
dDsgdG8gc2VydmljZSB1c2luZyBSZXN0YXJ0IFNlcnZpY2VDaGFuZ2UgY29tbWFuZCwgd2hhdCB0
aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IGNvbnRleHQgb2Yg
dGhlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyB0ZXJtaW5hdGlv
bnM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj4mZ3Q7IHdpbGwgYmUuIFZl
cnNpb24gMTEgZGlkIG1lbnRpb24gdGhpcyBhcyAmcXVvdDt0aGUgVGVybWlhbnRpb25zIGFyZTwv
Rk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDsgYXNzdW1lZCB0byBub3cg
bm90PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Jmd0OyBiZTwvRk9OVD4N
CjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDsgYXNzb2NpYXRlZCB3aXRoIGFueSBD
b250ZXh0JnF1b3Q7LjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZndDs8
L0ZPTlQ+DQo8L1A+DQo8L1VMPg0KPC9CT0RZPg0KPC9IVE1MPg0K

--0__=MJH5EQW4S9tflyorjYpX2h0apoFVN3EHik4XkDwSzZZ1Hs49enyFT7QP--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:28 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23982
	for ; Fri, 28 Jan 2000 14:05:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0BC35780@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12328 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:31 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.E6692170@standards.nortelnetworks.com>; Thu, 27 Jan 2000 23:54:51
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA08083 for
          ; Fri, 28 Jan 2000 10:54:57
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256874.001A973C ; Fri, 28 Jan 2000 10:20:26 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256874.001A9591.00@sandesh.hss.hns.com>
Date:         Fri, 28 Jan 2000 10:23:49 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Cisco SG16: Command Atomicity
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This issue has another consequence. For example while processing MOVE command
if any event need to be NOTIFIED to MGC, then this notify message need to be
delayed
till the time response of move is sent. This introduces latency in sending the
notify message
which by its purpose should not be delayed (MOVE has to tear down old star
connection
and create a new one in the destination context which may take time).

Any comments >>>






Chip Sharp  on 01/26/2000 05:35:49 AM

Please respond to Chip Sharp 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Cisco SG16:  Command Atomicity




Section:        8
Category:       Technical, Editorial
Issue:          It is unclear if commands are atomic or not. More specifically,
if
a command contains signals, events or digit map descriptors, will they
still be applied if the command fails ? If not, should the state of the
termination be reset (i.e. clear the signals, events, digit map named in
the command that has failed, as in MGCP 0.1) or maintained (i.e. as if the
command is not received, as in MGCP 1.0) ?
Proposal:       It is recommended that commands are atomic so that failed
commands leave the gateway in a well known state. It is furthermore
proposed, that a response descriptor should be added to the responses so
that if a command fails, the gateway can provide more information to the
MGC, rather than just an error code, e.g. for redirection.

v13 Status:     OPEN. No relevant text changed.


Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:32 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23993
	for ; Fri, 28 Jan 2000 14:05:29 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C062CE0@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12342 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:31 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C01EDB10@standards.nortelnetworks.com>; Fri, 28 Jan 2000 0:15:15
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA09646 for
          ; Fri, 28 Jan 2000 11:15:22
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256874.001C73D3 ; Fri, 28 Jan 2000 10:40:46 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256874.001C723A.00@sandesh.hss.hns.com>
Date:         Fri, 28 Jan 2000 10:44:09 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      EventIDs/SignalIDs in packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Although there is no restriction on the way ID values are given to various items
in all the packages, but is there any specific logic for selecting IDs in some
of
packages starting from 0 while in some other they strat from 30 or 10 or ...

Also the propertyID values are not assigned in base root package for all
properties


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24006
	for ; Fri, 28 Jan 2000 14:05:33 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C48DB30@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12358 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:32 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D5079800@standards.nortelnetworks.com>; Fri, 28 Jan 2000 1:27:25
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id MAA15750 for
          ; Fri, 28 Jan 2000 12:27:36
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256874.00230F10 ; Fri, 28 Jan 2000 11:52:56 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256874.00230DC9.00@sandesh.hss.hns.com>
Date:         Fri, 28 Jan 2000 11:56:17 +0530
Reply-To: bmbabu@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Madhu Babu 
Subject:      Summary of $, *, MOVE, ServiceChange
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I suggest that we should adopt this practice:
1. The special values $, * both for contexts and terminations have defined
meaning that
is not dictated by the command functionality they appear in:
ContextID * means ALL contexts (not ANY context in some cases as SUBTRACT C=*
T=foo*,or T=*, or T=specified)
ContextID $ means ALLOCATE a new one (not FIND a context as in SUBTRACT C=$ T=
... as above...)
TermID * means ALL terminations
TermID $ means ALLOCATE ephemeral (Don't look at media descriptor)
TermID foo* means ALL that START with foo
TermID foo$ means CHOOSE a physical (Don't look at media descriptor)

2. Some commands are termination oriented and the appearance of contextID
doesn't
carry any meaning. No validation of contextID should be done for these commands
These are ServiceChange and Audit (Auditing termination whether in context or
not)
(Subtract ??? For Subtract the only meaning
of context is NULL or non-NULL. specific contextID do not have a meaning because
a
termination belongs to a single context and subtraction is moving to NULL from
that single context.
specific contextID is used by MGC only to help MG easily locate the context or
may be for
more commands for the same context.)

3. ADD and MOVE are related to both termination and context.

(what about other commands ???)

Madhu
Sachin
Hughes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:41 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24018
	for ; Fri, 28 Jan 2000 14:05:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C8BB090@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12504 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:32 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.4B26FF40@standards.nortelnetworks.com>; Fri, 28 Jan 2000
          8:33:03 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 28 Jan 2000 07:32:39 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 28 Jan 2000 08:32:23
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Fri, 28 Jan 2000 07:32:21 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 28 Jan 2000 07:32:17 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      FW: Re: Stopping of Dial Tone
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Resend -- first attempt got swallowed.

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Wednesday, January 26, 2000 12:46 PM
> To:   'Megaco'
> Subject:      Re: Stopping of Dial Tone
>
> The problem is real.  The question is what event detection mechanism to
> use to stop dial tone.  It doesn't matter whether we define a new start of
> dialling event or simply use the existing dd/* ("detect any DTMF digit"):
> there is a problem of potential interaction with the digit map.  The most
> straightforward solution is that the MGC has to ask that the first digit
> be reported, and only after that it can send down a digit map for
> everything else.  Alternatively we have to modify section 7.1.8 to make it
> clear that it is possible to request digit detection in parallel with
> digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> individual digit events are detected, but the same digits are also
> processed by the digit map.
>
> Comments?
>
>
>                     From:         Madhu Babu 
>                     Subject:      Stopping of Dial tone
>
>
>                     Hi all,
>
>                     According to the example in the Appendix A.1.2 when
> MGC request
>                     MG to apply dial tone and check for digit events it is
> specified
>                     as
>
>                     Events = 2223 {
>                     al/on, dd/ce {DigitMap=Dialplan0}
>                     }
>                     Signals {cg/dt},
>
>                     According to the protocol an signal is stopped
> Whenever any
>                     event occurs. and here the event requested by MGC is
> digitmap
>                     completion,that means dial tone will be stopped when
> we get
>                     all the digits (as implied by the name digitmap
> completion).
>                     What I suggest is that a new event like
> "firstdigitcompletion"
>                     should also  be specified, otherwise how can the first
> digit itself
>                     stops the dialtone.
>
>                     regards
>                     -Madhubabu
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24047
	for ; Fri, 28 Jan 2000 14:05:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0CCE5EE0@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12554 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:33 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.47F20BA0@standards.nortelnetworks.com>; Fri, 28 Jan 2000
          8:54:26 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 28 Jan 2000 07:55:37 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Fri, 28
          Jan 2000 08:55:19 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Fri, 28 Jan 2000 08:55:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6997.4F234374"
Message-ID:  
Date:         Fri, 28 Jan 2000 08:55:16 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: BufferedEventHandling
X-To:         Chip Sharp 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6997.4F234374
Content-Type: text/plain

I think the onus is on you at this point to show that the current text is
broken.

> -----Original Message-----
> From: Chip Sharp [SMTP:chsharp@cisco.com]
> Sent: Thursday, January 27, 2000 4:31 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: BufferedEventHandling
>
> I disagreed with what I heard at the design team meeting at the meeting.
> I am proposing we keep what we have had for several months before the
> Washington meeting rather than replace it with a whole new mechanism.
>
> Chip
>
> At 12:44 PM 1/27/00 -0500, Tom-PT Taylor wrote:
>
> >Event handling received a LOT of discussion in Washington.  The existing
> >text dates from there; I can't see revisiting the issue.
> >-----Original Message-----  From:   Chip Sharp
> >[SMTP:chsharp@CISCO.COM]  Sent:   Tuesday, January 25, 2000 6:23
> >PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  Subject:
> >BufferedEventHandling
> >
> >Section:        7.1.7  Category:       Technical, Open
> >Issue  Issue:          At the end of the Red Bank meeting, Section 7.1.7
> >on  LocalControlDescriptor (Section 7.1.8 in TD-58 from the Red Bank
> >meeting  [3]), contained the following text: "The TerminationBuffered
> >parameter  describes actions taken by the MG when events are not
> >immediately notified  to the
> >controller.  1.      BufferedEventProcessingMode  specifies whether
> >buffered events should be  processed (Process) or discarded
> >(Discard)  2.      BufferedEventNotificationMode  specifies whether the
> >Media Gateway is  expected to detect the requested event and notify the
> >controller once (step  by step) or repeatedly (Loop).  The white
> >contribution does not contain this text which constitutes a  significant
> >technical change to the operation of event detection and  notification
> >which we strongly disagree with.  Discussion:             It is
> >recommended that the above deleted text is added to  Section 7.1.7 again.
> >
> >v13 Status:     WIDE OPEN. Text still missing. Extensive modification of
> >entire  event processing has taken place.
> >
> >Section:        7.2.7, second last paragraph  Category:       Technical,
> >Open Issue  Issue:          The draft text specifies that "If the
> >BufferedEventProcessingMode  parameter of the Termination is set to
> >"Discard", then the list shall  contain only the event that triggered the
>
> >notification".  This constitutes a significant technical change to the
> >operation of event  detection as indicated earlier for Section 7.1.7. The
>
> >text was not present  at the end of the Red Bank meeting [3], nor should
> >it be. Furthermore, the  text does not seem to make much sense; if an
> >event is not to be reported,  then it is simply not included in the
> >EventsDescriptor. This relates to the  removal of the
> >BufferedEventNotificationMode which should not have
> >happened.  Discussion:     It is strongly recommended that the
> >specification on event  buffering concerning both notification and
> >processing is revisited and  brought back in line with the outcome of the
>
> >Red Bank meeting.
> >
> >v13 Status:     OPEN. Although the text has been removed, it is part of
> >an  extensive modification of the entire event handling mechanism.
> >
> >Support
> >NetAid!  http://www.netaid.org
> >--------------------------------------------------  Chip
> >Sharp                 Consulting Engineering  Cisco
> >Systems              Telco Bio-region  Reality - Love it or Leave
> >it.  --------------------------------------------------
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

------_=_NextPart_001_01BF6997.4F234374
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: BufferedEventHandling




        I think the onus is =
on you at this point to show that the current text is broken.

        

          

          -----Original Message-----

          From:   Chip Sharp [SMTP:chsharp@cisco.com]

          Sent:   Thursday, January 27, 2000 4:31 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: BufferedEventHandling

          


          I disagreed with what I heard at the =
design team meeting at the meeting.

          I am proposing we keep what we have =
had for several months before the 

          Washington meeting rather than =
replace it with a whole new mechanism.

          


          Chip

          


          At 12:44 PM 1/27/00 -0500, Tom-PT =
Taylor wrote:

          


          >Event handling received a LOT of =
discussion in Washington.  The existing 

          >text dates from there; I can't =
see revisiting the issue.

          >-----Original Message-----  =
From:   Chip Sharp 

          >[SMTP:chsharp@CISCO.COM]  =
Sent:   Tuesday, January 25, 2000 6:23 

          >PM  =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM  =
Subject: 

          >BufferedEventHandling

          >

          >Section:        =
7.1.7  Category:       Technical, =
Open 

          >Issue  =
Issue:          At the end =
of the Red Bank meeting, Section 7.1.7 

          >on  LocalControlDescriptor =
(Section 7.1.8 in TD-58 from the Red Bank 

          >meeting  [3]), contained the =
following text: "The TerminationBuffered 

          >parameter  describes actions =
taken by the MG when events are not 

          >immediately notified  to the =


          >controller.  =
1.      BufferedEventProcessingMode  =
specifies whether 

          >buffered events should be  =
processed (Process) or discarded 

          >(Discard)  =
2.      BufferedEventNotificationMode  =
specifies whether the 

          >Media Gateway is  expected =
to detect the requested event and notify the 

          >controller once (step  by =
step) or repeatedly (Loop).  The white 

          >contribution does not contain =
this text which constitutes a  significant 

          >technical change to the operation =
of event detection and  notification 

          >which we strongly disagree =
with.  =
Discussion:          &=
nbsp;  It is 

          >recommended that the above =
deleted text is added to  Section 7.1.7 again.

          >

          >v13 =
Status:     WIDE OPEN. Text still missing. =
Extensive modification of 

          >entire  event processing has =
taken place.

          >

          >Section:        =
7.2.7, second last paragraph  =
Category:       Technical, 

          >Open Issue  =
Issue:          The draft =
text specifies that "If the 

          >BufferedEventProcessingMode  =
parameter of the Termination is set to 

          >"Discard", then the =
list shall  contain only the event that triggered the 

          >notification".  This =
constitutes a significant technical change to the 

          >operation of event  =
detection as indicated earlier for Section 7.1.7. The 

          >text was not present  at the =
end of the Red Bank meeting [3], nor should 

          >it be. Furthermore, the  =
text does not seem to make much sense; if an 

          >event is not to be =
reported,  then it is simply not included in the 

          >EventsDescriptor. This relates to =
the  removal of the 

          >BufferedEventNotificationMode =
which should not have 

          >happened.  =
Discussion:     It is strongly recommended that the =


          >specification on event  =
buffering concerning both notification and 

          >processing is revisited and  =
brought back in line with the outcome of the 

          >Red Bank meeting.

          >

          >v13 =
Status:     OPEN. Although the text has been =
removed, it is part of 

          >an  extensive modification =
of the entire event handling mechanism.

          >

          >Support 

          >NetAid!  =
<http://www.netaid.org>http://www.netaid.org 

          >--------------------------------------------------&nb=
sp; Chip 

          >Sharp        =
         Consulting =
Engineering  Cisco 

          >Systems       &nbs=
p;      Telco Bio-region  Reality - Love =
it or Leave 

          >it.  =
--------------------------------------------------

          


          Support NetAid!  http://www.netaid.org

          --------------------------------------------------=


          Chip =
Sharp           &=
nbsp;     Consulting Engineering

          Cisco =
Systems           =
;   Telco Bio-region

          Reality - Love it or Leave it.  =
        =
        

          --------------------------------------------------=


          

        


------_=_NextPart_001_01BF6997.4F234374--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:05:53 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24059
	for ; Fri, 28 Jan 2000 14:05:49 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D113440@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:00:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12988 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 13:59:33 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.31ADB250@standards.nortelnetworks.com>; Fri, 28 Jan 2000
          12:57:12 -0500
Received: from zmers013 by smtprch1.nortel.com; Fri, 28 Jan 2000 11:56:40 -0600
Received: from zrchb213.us.nortel.com by zmers013; Fri, 28 Jan 2000 12:56:08
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Fri, 28 Jan 2000 11:56:07 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Fri, 28 Jan 2000 11:56:04 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Announcements
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have two announcements for the list.

First: the IESG has approved our requirements document for puyblication as
an RFC.

Secondly, H.248v14, the version submitted to the ITU, is on the Megaco site

ftp://standards.nortelnetworks.com/megaco/docs/latest/

The file names are:

MegacoH248v14doc.zip (changebarred against v12)
MegacoH248v14.PDF (changebarred against v12)

Congratulations and many thanks to our editors.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:40:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24943
	for ; Fri, 28 Jan 2000 14:40:06 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3A462240@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:37:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13079 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 14:36:11 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9FEA19F0@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:26:11
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA20922; Fri, 28 Jan
          2000 14:27:55 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA14845; Fri, 28 Jan
          2000 14:27:58 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 28 Jan 2000 14:24:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF69C5.5A25C804"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20885C@whq-msgusr-02.fore.com>
Date:         Fri, 28 Jan 2000 14:27:55 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Virtual MG & Root
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF69C5.5A25C804
Content-Type: text/plain;
        charset="iso-8859-1"

The problem is Restart of Root.  This is a "warm boot".  If one Virtual MG
does it,
it will happen to all Virtual MGs unless you have a pretty complex
implementation
that can "fake" a warm boot without actually restarting the system.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Thursday, January 27, 2000 4:33 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Virtual MG & Root



I think this is a reasonable proposal.  When the sentence in question was
placed there, people had visions of one MGC knocking out the whole
(physical) MG.  If we simply interpret ServiceChange to be limited in scope
to the virtual MG, it allows, for instance, an MGC to shed load by handing
over responsibility for that virtual MG to another controller.

        -----Original Message-----
From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
Sent:   Tuesday, January 25, 2000 8:08 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Cisco SG16: Virtual MG & Root

        Section:        11.1, second last paragraph
Category:       Technical/Editorial
Issue:          The draft text specifies that "Each virtual MG has its own
Root
Termination" but "ServiceChange may only be applied to the Root by the
Master MGC". The two statements seem to be inconsistent as the purpose of
the virtual MG (and thereby the root termination for that virtual MG) is to
allow the MGC for the virtual MG to control that virtual MG.
Proposal:       It is proposed, that the last sentence is removed since each

virtual MG has its own Root termination.

        v13 Status:     OPEN. No relevant text changed.

        Support NetAid!  http://www.netaid.org 
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


------_=_NextPart_001_01BF69C5.5A25C804
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Virtual MG & Root




        The
problem is Restart of Root.  This is a "warm boot".  If one Virtual MG
does it,
        

        it
will happen to all Virtual MGs unless you have a pretty complex
implementation
        

        that
can "fake" a warm boot without actually restarting the
system.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Thursday, January 27, 2000
  4:33 PM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Cisco SG16: Virtual MG & Root

        
  
        I think this is a reasonable
  proposal.  When the sentence in question was placed there, people had
  visions of one MGC knocking out the whole (physical) MG.  If we simply
  interpret ServiceChange to be limited in scope to the virtual MG, it allows,
  for instance, an MGC to shed load by handing over responsibility for that
  virtual MG to another controller.
        
  
          
    
          -----Original Message----- 
          From:   Chip
    Sharp [SMTP:chsharp@CISCO.COM] 
          Sent:   Tuesday, January
    25, 2000 8:08 PM 
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
          Subject:        Cisco SG16: Virtual MG & Root 
          
    
          Section:        11.1, second last
    paragraph 
          Category:      
    Technical/Editorial 
          Issue:          The
    draft text specifies that "Each virtual MG has its own Root 
          Termination" but "ServiceChange may only be applied to the
    Root by the 
          Master MGC". The two
    statements seem to be inconsistent as the purpose of 
          the virtual MG (and thereby the root termination for that
    virtual MG) is to 
          allow the MGC for the
    virtual MG to control that virtual MG. 
          Proposal:       It is proposed, that
    the last sentence is removed since each 
          virtual MG has its own Root termination. 
          
    
          v13 Status:     OPEN. No
    relevant text changed. 
          
    
          Support NetAid!  http://www.netaid.org 
          -------------------------------------------------- 
          Chip
    Sharp                
    Consulting Engineering 
          Cisco
    Systems             
    Telco Bio-region 
          Reality - Love it or
    Leave it. 
          --------------------------------------------------

        

------_=_NextPart_001_01BF69C5.5A25C804--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 14:52:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25206
	for ; Fri, 28 Jan 2000 14:52:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA44A620@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:49:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13087 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 14:48:18 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.515A2F30@standards.nortelnetworks.com>; Fri, 28 Jan 2000 14:38:18
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA22268; Fri, 28 Jan
          2000 14:40:04 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA17670; Fri, 28 Jan
          2000 14:40:07 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Fri, 28 Jan 2000 14:37:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF20885D@whq-msgusr-02.fore.com>
Date:         Fri, 28 Jan 2000 14:40:03 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Command Atomicity
X-To:         "samittal@hss.hns.com" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I have advocated since day one that commands should be atomic.
Indeed, I believe transactions should be atomic.  I was
in a minority who believed that backing out of
a failed transaction a couple of commands in was too hard.

Now we notice that same applies to a command, a couple of
descriptors in.  If a command is atomic, and it fails, then
you have to back out of whatever you started, and leave the
state of the MG the same as it was before you started
executing the command.

Count me as in favor of atomic commands.
Of course, count me as in favor of atomic transactions, although
it's probably easier to back out of a command than a transaction;
not much easier, but easier.

Note that the text now recommends additional information be
appended to an error descriptor.  I think codifying such behavior
is better left for another day; we need more experience before
we try to write down what ought to be included.

Your specific issue with MOVE's interaction with NOTIFY is
a little puzzling.  I'm guessing you are worried that
there is an active EventsDescriptor on a termination, and then
you MOVE that termination to another context.  The question
arises, what should occur if the event happens during the processing
of the MOVE.

This is a kind of race condition.  If the MGC has left itself open
for such a problem, then it had better not matter to it that it
could see a Notify from an earlier EventsDescriptor after it sends
a Move.  If the Move arrived after the Notify was issued, the problem
is the same as if the Notify were issued in the middle of, or even
after the Move.

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Thursday, January 27, 2000 11:54 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Command Atomicity
>
>
> This issue has another consequence. For example while
> processing MOVE command
> if any event need to be NOTIFIED to MGC, then this notify
> message need to be
> delayed
> till the time response of move is sent. This introduces
> latency in sending the
> notify message
> which by its purpose should not be delayed (MOVE has to tear
> down old star
> connection
> and create a new one in the destination context which may take time).
>
> Any comments >>>
>
>
>
>
>
>
> Chip Sharp  on 01/26/2000 05:35:49 AM
>
> Please respond to Chip Sharp 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Cisco SG16:  Command Atomicity
>
>
>
>
> Section:        8
> Category:       Technical, Editorial
> Issue:          It is unclear if commands are atomic or not.
> More specifically,
> if
> a command contains signals, events or digit map descriptors, will they
> still be applied if the command fails ? If not, should the
> state of the
> termination be reset (i.e. clear the signals, events, digit
> map named in
> the command that has failed, as in MGCP 0.1) or maintained
> (i.e. as if the
> command is not received, as in MGCP 1.0) ?
> Proposal:       It is recommended that commands are atomic so
> that failed
> commands leave the gateway in a well known state. It is furthermore
> proposed, that a response descriptor should be added to the
> responses so
> that if a command fails, the gateway can provide more
> information to the
> MGC, rather than just an error code, e.g. for redirection.
>
> v13 Status:     OPEN. No relevant text changed.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 18:47:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29828
	for ; Fri, 28 Jan 2000 18:47:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEDE2C00@standards.nortelnetworks.com>; Fri, 28 Jan 2000 18:45:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13443 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 18:43:42 -0500
Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9917D850@standards.nortelnetworks.com>; Fri, 28 Jan 2000 18:43:41
          -0500
Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by
          mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id
          PAA15643; Fri, 28 Jan 2000 15:40:25 -0800 (PST)
X-Sender: chsharp@dogwood.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <4.2.2.20000128182438.00ac4bb0@dogwood.cisco.com>
Date:         Fri, 28 Jan 2000 18:27:43 -0500
Reply-To: Chip Sharp 
Sender: "Media Gateway Control (megaco)"
              
From: Chip Sharp 
Subject:      Re: BufferedEventHandling
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  

It was never proven that the previous status was broken.

There was a change in this  text between the output of SG16 in Red Bank
(TD58) and the white contribution (which became v12).

There was a comprehensive reworking of event handling in v13.

We are evaluating the current event handling mechanism and will provide
further comment when completed.

Chip

At 08:55 AM 1/28/00 -0500, Tom-PT Taylor wrote:

>I think the onus is on you at this point to show that the current text is
>broken.
>-----Original Message----- From:  Chip Sharp [SMTP:chsharp@cisco.com]
>Sent:  Thursday, January 27, 2000 4:31 PM To:    Taylor, Tom-PT
>[CAR:B904:EXCH]; MEGACO@STANDARDS.NORTELNETWORKS.COM Subject:       Re:
>BufferedEventHandling
>
>I disagreed with what I heard at the design team meeting at the meeting. I
>am proposing we keep what we have had for several months before the
>Washington meeting rather than replace it with a whole new mechanism.
>
>Chip
>
>At 12:44 PM 1/27/00 -0500, Tom-PT Taylor wrote:
>
> >Event handling received a LOT of discussion in Washington.  The
> existing >text dates from there; I can't see revisiting the
> issue. >-----Original Message-----  From:   Chip
> Sharp >[SMTP:chsharp@CISCO.COM]  Sent:   Tuesday, January 25, 2000
> 6:23 >PM  To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: >BufferedEventHandling > >Section:        7.1.7  Category:
> Technical, Open >Issue  Issue:          At the end of the Red Bank
> meeting, Section 7.1.7 >on  LocalControlDescriptor (Section 7.1.8 in
> TD-58 from the Red Bank >meeting  [3]), contained the following text:
> "The TerminationBuffered >parameter  describes actions taken by the MG
> when events are not >immediately notified  to
> the >controller.  1.      BufferedEventProcessingMode  specifies
> whether >buffered events should be  processed (Process) or
> discarded >(Discard)  2.      BufferedEventNotificationMode  specifies
> whether the >Media Gateway is  expected to detect the requested event and
> notify the >controller once (step  by step) or repeatedly (Loop).  The
> white >contribution does not contain this text which constitutes
> a  significant >technical change to the operation of event detection
> and  notification >which we strongly disagree
> with.  Discussion:             It is >recommended that the above deleted
> text is added to  Section 7.1.7 again. > >v13 Status:     WIDE OPEN. Text
> still missing. Extensive modification of >entire  event processing has
> taken place. > >Section:        7.2.7, second last
> paragraph  Category:       Technical, >Open Issue  Issue:          The
> draft text specifies that "If the >BufferedEventProcessingMode  parameter
> of the Termination is set to >"Discard", then the list shall  contain
> only the event that triggered the >notification".  This constitutes a
> significant technical change to the >operation of event  detection as
> indicated earlier for Section 7.1.7. The >text was not present  at the
> end of the Red Bank meeting [3], nor should >it be. Furthermore,
> the  text does not seem to make much sense; if an >event is not to be
> reported,  then it is simply not included in the >EventsDescriptor. This
> relates to the  removal of the >BufferedEventNotificationMode which
> should not have >happened.  Discussion:     It is strongly recommended
> that the >specification on event  buffering concerning both notification
> and >processing is revisited and  brought back in line with the outcome
> of the >Red Bank meeting. > >v13 Status:     OPEN. Although the text has
> been removed, it is part of >an  extensive modification of the entire
> event handling
> mechanism. > >Support >NetAid!
> <http://www.netaid.org>http://www.netaid.org >-----
> ---------------------------------------------  Chip >Sharp
 >  Consulting Engineering  Cisco >Systems              Telco
> Bio-region  Reality - Love it or
> Leave >it.  --------------------------------------------------  Support
> NetAid! http://www.netaid.org
> -------------------------------------------------- Chip
> Sharp                 Consulting Engineering Cisco
> Systems              Telco Bio-region Reality - Love it or Leave
> it.                  --------------------------------------------------

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Jan 28 19:23:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00265
	for ; Fri, 28 Jan 2000 19:23:41 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB4F7F70@standards.nortelnetworks.com>; Fri, 28 Jan 2000 19:21:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13521 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 28 Jan 2000 19:20:59 -0500
Received: from centauri.starcon.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.68FF8A60@standards.nortelnetworks.com>; Fri, 28 Jan 2000 19:10:59
          -0500
Received: from dashaus.hothaus.com (g210-hothaus.starcon.com [216.13.167.210])
          by centauri.starcon.com (Post.Office MTA v3.5.3 release 223 ID#
          0-0U10L2S100V35) with ESMTP id com for
          ; Fri, 28 Jan 2000 16:10:31 -0800
Received: by DASHAUS with Internet Mail Service (5.5.2448.0) id ;
          Fri, 28 Jan 2000 16:09:54 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <308148F84AE4D211926D00805F6524585A20C3@DASHAUS>
Date:         Fri, 28 Jan 2000 16:09:53 -0800
Reply-To: Bob Lukas 
Sender: "Media Gateway Control (megaco)"
              
From: Bob Lukas 
Subject:      Non-Buffered EventHandling
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The change in text in v14 regarding Event handling has left me a little
confused about event handling when EventBuffer flag is off. The text is
explicit about the EventBuffer=on case, but only says
"If the EventBuffer flag is off when the new Events Descriptor is received,
the queue is flushed and no events are added to it. The default state of
EventBuffer is off.",
but section 7.1.5 says
"The EventBuffer flag specifies whether events are buffered following
detection of an event in the Events Descriptor, or processed immediately".

After a Notify transaction containing ObservedEvents, what happens to new
events detected while EventBuffer is off?
Are they discarded until a new Events Descriptor is received, queued then
flushed until/when a new Events Descriptor is received, or do they continue
to get matched and reported against the previous Events Descriptor?
My understanding is that new events would continue to be processed as per
the previous Events Descriptor, correct?

________________________________
Bob Lukas
Broadcom Canada
Richmond BC
blukas@broadcom.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Jan 29 14:47:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22651
	for ; Sat, 29 Jan 2000 14:47:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6C3DFA00@standards.nortelnetworks.com>; Sat, 29 Jan 2000 14:45:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14121 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 29 Jan 2000 14:43:09 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.28EF7260@standards.nortelnetworks.com>; Sat, 29 Jan 2000
          14:43:09 -0500
Received: from zmers013 by smtprch1.nortel.com; Sat, 29 Jan 2000 13:44:40 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Sat, 29
          Jan 2000 14:44:25 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sat, 29 Jan 2000 14:44:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6A91.3ED7B770"
Message-ID:  
Date:         Sat, 29 Jan 2000 14:44:21 -0500
Reply-To: Nancy-M Greene 
Sender: "Media Gateway Control (megaco)"
              
From: Nancy-M Greene 
Subject:      Re: Announcements - draft-05
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6A91.3ED7B770
Content-Type: text/plain

And, Brian has created an internet-draft from v14 - it is also on the
standards.nortelnetworks.com ftp site, and will soon be on the ietf ftp
site.

Go to
ftp://standards.nortelnetworks.com/megaco/docs/latest

and the file name is:

draft-ietf-megaco-protocol-05.txt

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

> ----------
> From:         Taylor, Tom-PT [CAR:B904:EXCH]
> Sent:         Friday, January 28, 2000 12:56 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Announcements
>
> I have two announcements for the list.
>
> First: the IESG has approved our requirements document for puyblication as
> an RFC.
>
> Secondly, H.248v14, the version submitted to the ITU, is on the Megaco
> site
>
> ftp://standards.nortelnetworks.com/megaco/docs/latest/
>
> The file names are:
>
> MegacoH248v14doc.zip (changebarred against v12)
> MegacoH248v14.PDF (changebarred against v12)
>
> Congratulations and many thanks to our editors.
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>

------_=_NextPart_001_01BF6A91.3ED7B770
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Announcements - draft-05




        And, Brian has =
created an internet-draft from v14 - it is also on the =
standards.nortelnetworks.com ftp site, and will soon be on the ietf ftp =
site.
        


        Go to 

        ftp://standards.nortelnetworks.com/megaco/docs/latest<=
/A>

        


        and the file name =
is:

         

        draft-ietf-megaco-protocol-05.txt

        


        Nancy

        -----------------------------------------------------------------=
---------

        Nancy M. Greene 

        Internet & Service =
Provider Networks, Nortel Networks

        T:514-271-7221 =
(internal:ESN853-1077) E:ngreene@nortelnetworks.com

        
        


------_=_NextPart_001_01BF6A91.3ED7B770--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 30 02:26:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10929
	for ; Sun, 30 Jan 2000 02:26:40 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.19335AF0@standards.nortelnetworks.com>; 30 Jan 2000 2:24:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14262 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 30 Jan 2000 02:22:21 -0500
Received: from alpha.netvision.net.il (194.90.1.13) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7073D9E0@standards.nortelnetworks.com>; 30 Jan 2000 2:12:20
          -0500
Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il
          [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP
          id JAA29794 for ; Sun, 30 Jan
          2000 09:14:04 +0200 (IST)
Received: from ismailweb.icomverse.com (ismailweb.icomverse.com
          [190.190.110.1]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id
          JAA17062 for ; Sun, 30 Jan 2000
          09:14:16 +0200
Received: by ismailwab with Internet Mail Service (5.5.2650.21) id ;
          Sun, 30 Jan 2000 09:14:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-2"
Message-ID:  <8B57BF666E1AD21181D900104B2E9B5ADB933C@ismailwab>
Date:         Sun, 30 Jan 2000 09:14:33 +0200
Reply-To: "Bohr, Merav" 
Sender: "Media Gateway Control (megaco)"
              
From: "Bohr, Merav" 
Subject:      MEGACO conference
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi All!

Is there any time soon a conference concerning MEGACO?

Sincerely,

Merav Bohr
VOIP / R&D Platform
Comverse Network Systems
+972-3-645-4198


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Jan 30 21:31:11 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13496
	for ; Sun, 30 Jan 2000 21:31:10 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FBD00CB0@standards.nortelnetworks.com>; 30 Jan 2000 21:28:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 14686 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 30 Jan 2000 21:27:30 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.D0119FD0@standards.nortelnetworks.com>; 30 Jan 2000 21:27:30
          -0500
Received: from zmers013 by smtprch1.nortel.com; Sun, 30 Jan 2000 20:27:32 -0600
Received: from zrchb213.us.nortel.com by zmers013; Sun, 30 Jan 2000 21:27:12
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Sun, 30 Jan 2000 20:27:10 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6B92.ACCF3562"
Message-ID:  
Date:         Sun, 30 Jan 2000 20:27:10 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Unspecified mandatory parameters
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6B92.ACCF3562
Content-Type: text/plain

I've been going through the list looking for open items.  I notice this
E-mail was never answered.  My own search of v14 shows that our
identification of mandatory parameters is spotty.  "Local" and "Remote" are
mandatory (see 7.1.8); so are some of the ServiceChange parameters.  I have
to wonder whether the rule of 7.1.1 (use previously specified values if
mandatory values are missing) has any meaning in the case of a
ServiceChange.

Leaving that aside, packages will specify mandatory and optional parameters,
particularly for events and signals.  Furthermore, within Local and Remote
the rules of SDP make a number of parameters mandatory.  I would have to
assume that the same parameters are mandatory when using Annex C encoding,
since Annex C should be functionally equivalent to SDP.

I see two possible issues here.  First, have we done all we need to, to
indicate which parameters are mandatory under what circumstances?  Second,
is the rule stated in 7.1.1 with respect to missing mandatory parameters too
broad, and should it be replaced by command-specific rules?

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Friday, January 14, 2000 9:33 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Unspecified mandatory parameters
>
> Hi
>
> In section 7.1.1
> "Unspecified mandatory parameters (i.e. mandatory parameters not specified
> in a descriptor)
> result in the command responder ..."
>
> Can someone give me an example of an unspecified mandatory parameter in a
> descriptor?
>
> Does this result in a syntax error?
> How do I tell if a parameter is mandatory - based ABNF?
>
> Thanks
> Chuong
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

------_=_NextPart_001_01BF6B92.ACCF3562
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Unspecified mandatory parameters




        I've been going =
through the list looking for open items.  I notice this E-mail was =
never answered.  My own search of v14 shows that our =
identification of mandatory parameters is spotty.  =
"Local" and "Remote" are mandatory (see 7.1.8); so =
are some of the ServiceChange parameters.  I have to wonder =
whether the rule of 7.1.1 (use previously specified values if mandatory =
values are missing) has any meaning in the case of a =
ServiceChange.
        


        Leaving that aside, =
packages will specify mandatory and optional parameters, particularly =
for events and signals.  Furthermore, within Local and Remote the =
rules of SDP make a number of parameters mandatory.  I would have =
to assume that the same parameters are mandatory when using Annex C =
encoding, since Annex C should be functionally equivalent to =
SDP.
        


        I see two possible =
issues here.  First, have we done all we need to, to indicate =
which parameters are mandatory under what circumstances?  Second, =
is the rule stated in 7.1.1 with respect to missing mandatory =
parameters too broad, and should it be replaced by command-specific =
rules?
        

          

          -----Original Message-----

          From:   Chuong Nguyen =
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]

          Sent:   Friday, January 14, 2000 9:33 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Unspecified mandatory =
parameters

          


          Hi 

          


          In section 7.1.1
          
"Unspecified mandatory parameters (i.e. mandatory parameters not =
specified in a descriptor)
          
result in the command responder ..."           

          


          Can someone give me an example of an =
unspecified mandatory parameter in a descriptor? 

          


          Does this result in a syntax error?
          
How do I tell if a parameter is mandatory - based ABNF?           

          


          Thanks
          
Chuong           

          --=A0
          
=A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: =
Chuong.Nguyen@usa.alcatel.com
          
=A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Phone:=A0=A0=A0 (972) 519-4613
          
=A0 **** The opinions expressed are not those of Alcatel USA, Inc =
****          

          =A0

          

        


------_=_NextPart_001_01BF6B92.ACCF3562--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 02:45:20 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29586
	for ; Mon, 31 Jan 2000 02:45:20 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DBDC6850@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:42:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15306 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 02:40:50 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.952ED730@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:40:49
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA11245 for
          ; Mon, 31 Jan 2000 13:41:13
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.0029CD7A ; Mon, 31 Jan 2000 13:06:35 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256877.0029CD29.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:10:03 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      v14: Change required in Audit command description
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In Section 7.2.5 & 6. the Audit descriptor is not shown to be optional but
auditRequest in grammar shows it to be optional.
This should be changed one way or the other.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 02:57:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29658
	for ; Mon, 31 Jan 2000 02:57:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.89C99860@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:54:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15318 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 02:53:12 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4DF324F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:53:08
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA11971 for
          ; Mon, 31 Jan 2000 13:53:33
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.002AEEC5 ; Mon, 31 Jan 2000 13:18:56 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256877.002AEDE3.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:22:22 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The point that "$" is for choosing ephemeral is not yet added in V14. Is it that
the discussion
is not yet complete? What about foo$ representing choose physical.




Sachin Mittal  on 01/27/2000 11:35:50 AM

Please respond to samittal@hns.com

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.




Its true that the type of termination should not be identified by looking into
the descriptor
information. Somewhere in the text this should be added that " $ if it appears
alone indicates
ephemeral termination and partial $ (ex foo$) indicates selection of a physical
termination
(a circuit within a trunk group)".




"Rosen, Brian"  on 01/27/2000 02:36:46 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.




Generally determined by the "kind" of termination requested.
Which is in turn, easily discernable from the Media command.

However, upon reflection, I think it's not a good answer.
I'd propose that we not allow selection of a physical termination,
in which case choose is always create an ephemeral.  In particular,
the following is perfectly legal:
Context=${Add=${}}
What do you get?

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Tuesday, January 25, 2000 9:01 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Choosing of ephemeral / physical Termination.
>
>
> Annex B.1 says that "The CHOOSE TerminationID $ may be used
> to signal to the MG
> that it has to create an
> ephemeral Termination or select an idle physical Termination".
> How can MG determine when to create an ephemeral termination
> and when to choose
> idle physical termination.??
> What is the logic behind this decision making?
>
> regards
> -Sachin Mittal
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 02:57:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29660
	for ; Mon, 31 Jan 2000 02:57:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8A0C6DC0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:54:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15323 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 02:53:50 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.65513330@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:53:47
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA11504; Mon, 31 Jan
          2000 13:45:07 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.002A28EF ; Mon, 31 Jan 2000 13:10:29 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256877.002A270F.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:13:53 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: ServiceChange
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Can we add the text "If a command other than Subtract (or ServiceChange) was
received on a
termination that is out of service, an error should be returned." somewhere in
the document.






"Rosen, Brian"  on 01/27/2000 09:21:55 PM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: ServiceChange




I believe the MG should do what the MGC says.

The MGC is responsible for making the state consistent, and this
means getting the Subtract through.

A termination could be out of service, but still in a context,
and would be under failure conditions.  The MGC must run the
Subtract command to get the state reasonable.

If a command other than Subtract (or ServiceChange) was received on a
termination that is out of service, an error should be returned.

Brian

> -----Original Message-----
> From: Madhu Babu [mailto:bmbabu@hss.hns.com]
> Sent: Thursday, January 27, 2000 5:00 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: ServiceChange
>
>
> When a termination is marked out-of-service through
> ServiceChange command
> using graceful/ forced ServiceChangeMethod, and MGC has not
> yet sent Subtract
> command for that termination, what is the processing
> associated at MG when
> second
> ServiceChange command arrives with Restart method. Should it
> be removed from
> context or disallow second ServiceChange command?
>
> There is no text in Version 13  mentioning that when
> terminations are brought
> back
> to service using Restart ServiceChange command, what the
> context of the
> terminations
> will be. Version 11 did mention this as "the Termiantions are
> assumed to now not
> be
> associated with any Context".
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 02:59:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29681
	for ; Mon, 31 Jan 2000 02:59:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D1D5A810@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:56:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15328 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 02:55:05 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.9266F2B0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:55:03
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA12092; Mon, 31 Jan
          2000 13:55:14 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.002B138A ; Mon, 31 Jan 2000 13:20:30 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=9ni2AklmcWe80XOkaPF9NQJRPXGm2NSCxzMDyS5Po1d3AhGk0qREcLNa"
Content-Disposition: inline
Message-ID:  <65256877.002B122B.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:23:55 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: ServiceChange in Null context.
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=9ni2AklmcWe80XOkaPF9NQJRPXGm2NSCxzMDyS5Po1d3AhGk0qREcLNa
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Need to add this in text. Somehow missed in V14.




Tom-PT Taylor  on 01/28/2000 02:30:21 AM

Please respond to Tom-PT Taylor 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: ServiceChange in Null context.




Another good point.  In the NULL context the state should immediately go to
"out of service".  No need to be graceful when the termination isn't
actively involved in a call.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Thursday, January 27, 2000 3:53 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ServiceChange in Null context.
>
> According to Section 7.2.8 it is mentioned that when a termination
> receives
> ServiceChange
> command with graceful ServiceChangeMethod and ServiceChangeDelay = NULL
> then
> MG should set state= "test" and INDEFINITELY wait for Subtract command.
> what is the behavior of MG when the termination is in NULL context?


--0__=9ni2AklmcWe80XOkaPF9NQJRPXGm2NSCxzMDyS5Po1d3AhGk0qREcLNa
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI0NDguMCI+DQo8VElUTEU+UkU6IFNlcnZp
Y2VDaGFuZ2UgaW4gTnVsbCBjb250ZXh0LjwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCg0KPFA+
PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlhbCI+QW5vdGhlciBnb29kIHBv
aW50LiZuYnNwOyBJbiB0aGUgTlVMTCBjb250ZXh0IHRoZSBzdGF0ZSBzaG91bGQgaW1tZWRpYXRl
bHkgZ28gdG8gJnF1b3Q7b3V0IG9mIHNlcnZpY2UmcXVvdDsuJm5ic3A7IE5vIG5lZWQgdG8gYmUg
Z3JhY2VmdWwgd2hlbiB0aGUgdGVybWluYXRpb24gaXNuJ3QgYWN0aXZlbHkgaW52b2x2ZWQgaW4g
YSBjYWxsLjwvRk9OVD48L1A+DQo8VUw+DQo8UD48Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9MSBGQUNF
PSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0i
QXJpYWwiPlNhY2hpbiBNaXR0YWwgW1NNVFA6c2FtaXR0YWxASFNTLkhOUy5DT01dPC9GT05UPg0K
PEJSPjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U2VudDombmJzcDsmbmJzcDs8L0ZPTlQ+
PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlRodXJzZGF5LCBKYW51YXJ5IDI3LCAyMDAw
IDM6NTMgQU08L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFsIj5UbzombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwi
Pk1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0KPEJSPjxCPjxGT05U
IFNJWkU9MSBGQUNFPSJBcmlhbCI+U3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlNlcnZp
Y2VDaGFuZ2UgaW4gTnVsbCBjb250ZXh0LjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5BY2NvcmRpbmcgdG8gU2VjdGlvbiA3LjIuOCBpdCBpcyBtZW50aW9uZWQg
dGhhdCB3aGVuIGEgdGVybWluYXRpb24gcmVjZWl2ZXM8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y
IEZBQ0U9IkFyaWFsIj5TZXJ2aWNlQ2hhbmdlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNF
PSJBcmlhbCI+Y29tbWFuZCB3aXRoIGdyYWNlZnVsIFNlcnZpY2VDaGFuZ2VNZXRob2QgYW5kIFNl
cnZpY2VDaGFuZ2VEZWxheSA9IE5VTEwgdGhlbjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFD
RT0iQXJpYWwiPk1HIHNob3VsZCBzZXQgc3RhdGU9ICZxdW90O3Rlc3QmcXVvdDsgYW5kIElOREVG
SU5JVEVMWSB3YWl0IGZvciBTdWJ0cmFjdCBjb21tYW5kLjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpF
PTIgRkFDRT0iQXJpYWwiPndoYXQgaXMgdGhlIGJlaGF2aW9yIG9mIE1HIHdoZW4gdGhlIHRlcm1p
bmF0aW9uIGlzIGluIE5VTEwgY29udGV4dD88L0ZPTlQ+DQo8L1A+DQo8L1VMPg0KPC9CT0RZPg0K
PC9IVE1MPg0K

--0__=9ni2AklmcWe80XOkaPF9NQJRPXGm2NSCxzMDyS5Po1d3AhGk0qREcLNa--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 02:59:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29683
	for ; Mon, 31 Jan 2000 02:59:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D2377720@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:56:50 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15335 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 02:55:17 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.99A38480@standards.nortelnetworks.com>; Mon, 31 Jan 2000 2:55:15
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id NAA12107; Mon, 31 Jan
          2000 13:55:26 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.002B1BBF ; Mon, 31 Jan 2000 13:20:51 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=Dpy0JJBcETmIjxmwAA6WgI2YKOJ82yqU5TXMtwLilQNjNQ3W3u94Sg96"
Content-Disposition: inline
Message-ID:  <65256877.002B1A89.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:24:16 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Importance of ContextID in ServiceChange command
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=Dpy0JJBcETmIjxmwAA6WgI2YKOJ82yqU5TXMtwLilQNjNQ3W3u94Sg96
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Need to add this in text. Somehow missed in V14.




Tom-PT Taylor  on 01/28/2000 02:28:57 AM

Please respond to Tom-PT Taylor 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Importance of ContextID in ServiceChange command




Good point.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Thursday, January 27, 2000 4:07 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Importance of ContextID in ServiceChange command
>
> HI all
>
> It should be mentioned somewhere in the text that there is no
> siginificance of
> ContextID in case of ServiceChange Command. The ServiceChange command
> is for terminations and no validation is done on ContextID should be done.


--0__=Dpy0JJBcETmIjxmwAA6WgI2YKOJ82yqU5TXMtwLilQNjNQ3W3u94Sg96
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PXVzLWFzY2lpIj4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0i
TVMgRXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNS41LjI0NDguMCI+DQo8VElUTEU+UkU6IEltcG9y
dGFuY2Ugb2YgQ29udGV4dElEIGluIFNlcnZpY2VDaGFuZ2UgY29tbWFuZDwvVElUTEU+DQo8L0hF
QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgQ09MT1I9IiMwMDAwRkYiIFNJWkU9MiBGQUNFPSJBcmlh
bCI+R29vZCBwb2ludC48L0ZPTlQ+DQo8L1A+DQo8VUw+DQo8UD48Rk9OVCBTSVpFPTEgRkFDRT0i
QXJpYWwiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9GT05UPg0KPEJSPjxCPjxGT05UIFNJ
WkU9MSBGQUNFPSJBcmlhbCI+RnJvbTombmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpF
PTEgRkFDRT0iQXJpYWwiPlNhY2hpbiBNaXR0YWwgW1NNVFA6c2FtaXR0YWxASFNTLkhOUy5DT01d
PC9GT05UPg0KPEJSPjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U2VudDombmJzcDsmbmJz
cDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJpYWwiPlRodXJzZGF5LCBKYW51YXJ5
IDI3LCAyMDAwIDQ6MDcgQU08L0ZPTlQ+DQo8QlI+PEI+PEZPTlQgU0laRT0xIEZBQ0U9IkFyaWFs
Ij5UbzombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFD
RT0iQXJpYWwiPk1FR0FDT0BTVEFOREFSRFMuTk9SVEVMTkVUV09SS1MuQ09NPC9GT05UPg0KPEJS
PjxCPjxGT05UIFNJWkU9MSBGQUNFPSJBcmlhbCI+U3ViamVjdDombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+PC9CPiA8Rk9OVCBTSVpFPTEgRkFDRT0iQXJp
YWwiPkltcG9ydGFuY2Ugb2YgQ29udGV4dElEIGluIFNlcnZpY2VDaGFuZ2UgY29tbWFuZDwvRk9O
VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yIEZBQ0U9IkFyaWFsIj5ISSBhbGw8L0ZPTlQ+DQo8
L1A+DQoNCjxQPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+SXQgc2hvdWxkIGJlIG1lbnRpb25l
ZCBzb21ld2hlcmUgaW4gdGhlIHRleHQgdGhhdCB0aGVyZSBpcyBubyBzaWdpbmlmaWNhbmNlIG9m
PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+Q29udGV4dElEIGluIGNhc2Ug
b2YgU2VydmljZUNoYW5nZSBDb21tYW5kLiBUaGUgU2VydmljZUNoYW5nZSBjb21tYW5kPC9GT05U
Pg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+aXMgZm9yIHRlcm1pbmF0aW9ucyBhbmQg
bm8gdmFsaWRhdGlvbiBpcyBkb25lIG9uIENvbnRleHRJRCBzaG91bGQgYmUgZG9uZS48L0ZPTlQ+
DQo8L1A+DQo8L1VMPg0KPC9CT0RZPg0KPC9IVE1MPg0K

--0__=Dpy0JJBcETmIjxmwAA6WgI2YKOJ82yqU5TXMtwLilQNjNQ3W3u94Sg96--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 03:26:15 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29857
	for ; Mon, 31 Jan 2000 03:26:15 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9930A1A0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 3:23:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15364 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 03:22:35 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.F1C1C700@standards.nortelnetworks.com>; Mon, 31 Jan 2000 3:19:11
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id OAA13713 for
          ; Mon, 31 Jan 2000 14:19:36
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256877.002D51BB ; Mon, 31 Jan 2000 13:45:00 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256877.002D4FFC.00@sandesh.hss.hns.com>
Date:         Mon, 31 Jan 2000 13:48:25 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Cisco SG16: Command Atomicity
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I think that although MG is dumb and MGC has the full responsiblitiy
of command sequencing some kind of guidelines should be there for MGC.
A step in this direction is already taken by moving "Ordering of commands"
to section 9.1 from "transport over IP".

This can include cases like the race condition we discussed in this thread
and may be the following (taken from other thread):

Quote starts................
> The MGC is responsible for making the state consistent, and this
> means getting the Subtract through.
>
> A termination could be out of service, but still in a context,
> and would be under failure conditions.  The MGC must run the
> Subtract command to get the state reasonable.
>
> If a command other than Subtract (or ServiceChange) was received on a
> termination that is out of service, an error should be returned.
End quoted text...........................

One important thing about the above quoted text is that MG is also
co-operating with MGC for bringing the termination to a reasonable state






"Rosen, Brian"  on 01/29/2000 01:10:03 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Cisco SG16: Command Atomicity




I have advocated since day one that commands should be atomic.
Indeed, I believe transactions should be atomic.  I was
in a minority who believed that backing out of
a failed transaction a couple of commands in was too hard.

Now we notice that same applies to a command, a couple of
descriptors in.  If a command is atomic, and it fails, then
you have to back out of whatever you started, and leave the
state of the MG the same as it was before you started
executing the command.

Count me as in favor of atomic commands.
Of course, count me as in favor of atomic transactions, although
it's probably easier to back out of a command than a transaction;
not much easier, but easier.

Note that the text now recommends additional information be
appended to an error descriptor.  I think codifying such behavior
is better left for another day; we need more experience before
we try to write down what ought to be included.

Your specific issue with MOVE's interaction with NOTIFY is
a little puzzling.  I'm guessing you are worried that
there is an active EventsDescriptor on a termination, and then
you MOVE that termination to another context.  The question
arises, what should occur if the event happens during the processing
of the MOVE.

This is a kind of race condition.  If the MGC has left itself open
for such a problem, then it had better not matter to it that it
could see a Notify from an earlier EventsDescriptor after it sends
a Move.  If the Move arrived after the Notify was issued, the problem
is the same as if the Notify were issued in the middle of, or even
after the Move.

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Thursday, January 27, 2000 11:54 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Command Atomicity
>
>
> This issue has another consequence. For example while
> processing MOVE command
> if any event need to be NOTIFIED to MGC, then this notify
> message need to be
> delayed
> till the time response of move is sent. This introduces
> latency in sending the
> notify message
> which by its purpose should not be delayed (MOVE has to tear
> down old star
> connection
> and create a new one in the destination context which may take time).
>
> Any comments >>>
>
>
>
>
>
>
> Chip Sharp  on 01/26/2000 05:35:49 AM
>
> Please respond to Chip Sharp 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Cisco SG16:  Command Atomicity
>
>
>
>
> Section:        8
> Category:       Technical, Editorial
> Issue:          It is unclear if commands are atomic or not.
> More specifically,
> if
> a command contains signals, events or digit map descriptors, will they
> still be applied if the command fails ? If not, should the
> state of the
> termination be reset (i.e. clear the signals, events, digit
> map named in
> the command that has failed, as in MGCP 0.1) or maintained
> (i.e. as if the
> command is not received, as in MGCP 1.0) ?
> Proposal:       It is recommended that commands are atomic so
> that failed
> commands leave the gateway in a well known state. It is furthermore
> proposed, that a response descriptor should be added to the
> responses so
> that if a command fails, the gateway can provide more
> information to the
> MGC, rather than just an error code, e.g. for redirection.
>
> v13 Status:     OPEN. No relevant text changed.
>
>
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 06:37:42 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00974
	for ; Mon, 31 Jan 2000 06:37:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4FC2EAD0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 6:35:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15474 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 06:33:21 -0500
Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.113B8830@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          6:33:21 -0500
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA07996
          for ; Mon, 31 Jan 2000 06:35:20
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          GAA07986 for ; Mon, 31 Jan 2000
          06:35:19 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA06417; Mon,
          31 Jan 2000 12:35:15 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          MAA06412; Mon, 31 Jan 2000 12:35:15 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38957315.5DDD286E@lucent.com>
Date:         Mon, 31 Jan 2000 12:33:41 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: FW: Re: Stopping of Dial Tone
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom,

Is it really a problem?  The way I always understood this, is that
detection of an event stops an active signal.  It doesn't matter how the
event is detected or reported.  So an event that leads to a partial
match in a digit map (the first digit) would stop dialtone.

Is my thinking flawed?

John

Tom-PT Taylor wrote:
>
> Resend -- first attempt got swallowed.
>
> > -----Original Message-----
> > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > Sent: Wednesday, January 26, 2000 12:46 PM
> > To:   'Megaco'
> > Subject:      Re: Stopping of Dial Tone
> >
> > The problem is real.  The question is what event detection mechanism to
> > use to stop dial tone.  It doesn't matter whether we define a new start of
> > dialling event or simply use the existing dd/* ("detect any DTMF digit"):
> > there is a problem of potential interaction with the digit map.  The most
> > straightforward solution is that the MGC has to ask that the first digit
> > be reported, and only after that it can send down a digit map for
> > everything else.  Alternatively we have to modify section 7.1.8 to make it
> > clear that it is possible to request digit detection in parallel with
> > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> > individual digit events are detected, but the same digits are also
> > processed by the digit map.
> >
> > Comments?
> >
> >
> >                     From:         Madhu Babu 
> >                     Subject:      Stopping of Dial tone
> >
> >
> >                     Hi all,
> >
> >                     According to the example in the Appendix A.1.2 when
> > MGC request
> >                     MG to apply dial tone and check for digit events it is
> > specified
> >                     as
> >
> >                     Events = 2223 {
> >                     al/on, dd/ce {DigitMap=Dialplan0}
> >                     }
> >                     Signals {cg/dt},
> >
> >                     According to the protocol an signal is stopped
> > Whenever any
> >                     event occurs. and here the event requested by MGC is
> > digitmap
> >                     completion,that means dial tone will be stopped when
> > we get
> >                     all the digits (as implied by the name digitmap
> > completion).
> >                     What I suggest is that a new event like
> > "firstdigitcompletion"
> >                     should also  be specified, otherwise how can the first
> > digit itself
> >                     stops the dialtone.
> >
> >                     regards
> >                     -Madhubabu
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 06:57:40 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01102
	for ; Mon, 31 Jan 2000 06:57:39 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1C844C10@standards.nortelnetworks.com>; Mon, 31 Jan 2000 6:55:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15502 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 06:53:33 -0500
Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.E3A40E30@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          6:53:33 -0500
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA18461
          for ; Mon, 31 Jan 2000 06:55:32
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          GAA18451 for ; Mon, 31 Jan 2000
          06:55:31 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA08526; Mon,
          31 Jan 2000 12:55:30 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          MAA08520; Mon, 31 Jan 2000 12:55:30 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <389577D4.4C379171@lucent.com>
Date:         Mon, 31 Jan 2000 12:53:56 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Telcordia SG 16: Updates to References Section of H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom,

The reference section has been updated in the new draft.

Your remark that Annex C is SG 16's business puzzles me.  It seems to
imply that IETF is developing a text protocol and ITU a binary protocol,
while in actual fact, the two organizations are working on a joint
protocol with two encoding options.  It is up to the editors (both ITU
and IETF) to keep the two options aligned.

Comments about problems being the other groups's business do not support
this mode of operation.

Cheers,

John

> Tom-PT Taylor wrote:
>
> Agreed.  Not sure why SG 16 is doing this to themselves, but Annex C
> is their business.
>
>      -----Original Message-----
>      From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
>      Sent:   Thursday, January 27, 2000 8:52 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Telcordia SG 16: Updates to References Section of
>      H.248
>
>      The documents referenced in Annex C of H.248 (e.g., Q.763) should
>      be added as
>      normative references as they are needed to implement the
>      protocol.
>
>      Specifically, the following should be added as normative
>      references since they
>      are needed to implement the protocol of Annex C:
>
>      Q.1901  (informally known as Q.BICC)
>
>      Q.763-1999  (ISUP)
>
>      Q.2630  (AAL2 Signaling)
>
>      Q.2931  (B-ISDN Network Access Layer Signaling)
>
>      Q.2941.3  (Generic Identifier Transport
>      ? Extensions for BICC)
>
>      Q.931-1998 (N-ISDN Network Access Layer Signaling)
>
>      In addition, the reference to Q.931 in the Informative References
>      section should
>      be removed since it is being added to the Normative references
>      section.
>
>      Section 3.1 of a Telcordia Technologies contribution to SG 16
>      (which can be
>      found at
>      ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC
>      )
>      provides a proposal for updating the references.
>
>      -Selvam Rengasami
>      Telcordia Technologies
>      Tel:  +1 732 758 5260
>      E-mail:  srengasa@telcordia.com

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 07:07:37 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01213
	for ; Mon, 31 Jan 2000 07:07:37 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.839B5460@standards.nortelnetworks.com>; Mon, 31 Jan 2000 7:05:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15532 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 07:05:05 -0500
Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.7FC9B2F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          7:05:04 -0500
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA23425
          for ; Mon, 31 Jan 2000 07:07:04
          -0500 (EST)
Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31])
          by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id
          HAA23420 for ; Mon, 31 Jan 2000
          07:07:02 -0500 (EST)
Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA10072; Mon,
          31 Jan 2000 13:06:57 +0100 (MET)
Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id
          NAA10053; Mon, 31 Jan 2000 13:06:46 +0100 (MET)
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@standards.nortelnetworks.com
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <38957A78.32DD6AD@lucent.com>
Date:         Mon, 31 Jan 2000 13:05:12 +0100
Reply-To: John Segers 
Sender: "Media Gateway Control (megaco)"
              
From: John Segers 
Organization: Lucent Technologies
Subject:      Re: Telcordia SG16: CommandError in Annex A of H.248
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The clause for CommandError has been removed.

John

> Tom-PT Taylor wrote:
>
> We should probably review the whole collection of places in which the
> ASN.1 and ABNF show errorDescriptors -- it seems like there are a lot
> of them.  I can't find "CommandError" in Annex A of the version
> submitted to the ITU (shortly to be placed on the Megaco site), but
> that may be a misunderstanding.
>
>      -----Original Message-----
>      From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
>      Sent:   Thursday, January 27, 2000 9:16 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Telcordia SG16: CommandError in Annex A of H.248
>
>      In Annex A, the following term "CommandError" is defined,
>      however, it is not
>      tied to any transaction, action, or command.  It is not clear
>      what its use is.
>      H.248 should state what its relationship is to the other aspects
>      of the protocol
>      or should remove it.
>
>      It is proposed that the CommandError description in Annex A be
>      removed.
>
>      Section 3.6 of a Telcordia Technologies contribution to SG 16
>      (which can be
>      found at
>      ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC
>      )
>      provides a proposal for clarifying this issue.
>
>      -Selvam Rengasami
>      Telcordia Technologies
>      Tel:  +1 732 758 5260
>      E-mail:  srengasa@telcordia.com

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 07:43:58 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01565
	for ; Mon, 31 Jan 2000 07:43:58 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C01F500@standards.nortelnetworks.com>; Mon, 31 Jan 2000 7:41:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15558 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 07:39:34 -0500
Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.4E8599C0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 7:39:29
          -0500
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by
          mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id OAA09871; Mon, 31 Jan
          2000 14:41:22 +0200 (EET)
Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76])
          by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id OAA09794; Mon, 31
          Jan 2000 14:41:22 +0200 (EET)
Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com
          [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP
          id OAA12693; Mon, 31 Jan 2000 14:41:21 +0200 (EET)
Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id
          OAA09818; Mon, 31 Jan 2000 14:41:21 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H
        pfDMyJ`i=:M;BM3R.`[>P^ER8+]i
References:  <85256873.0048DC91.00@notes950.cc.telcordia.com>
X-Mailer: VM 6.72 under 21.1 (patch 7) "Biscayne" XEmacs Lucid
Message-ID:  <14485.33521.153980.192729@rama.research.nokia.com>
Date:         Mon, 31 Jan 2000 14:41:21 +0200
Reply-To: Pekka.Pessi@nokia.com
Sender: "Media Gateway Control (megaco)"
              
From: Pekka Pessi 
Subject:      Re: Telcordia SG 16: Lack of Propper Tagging in H.248
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <85256873.0048DC91.00@notes950.cc.telcordia.com>
Content-Transfer-Encoding: 7bit

Selvam Rengasami  writes:
>The ASN.1 specification of the protocol contained within Annex A lacks proper
>tagging for the defined parameters.  In order to clearly distinguish messages,
>parameters, and values included, unique tagging is an essential requirement of
>the protocol. Thus, with the existing specification, a receiving entity would
>have a difficult time trying to determine whether a received transaction
>contained an AddRequest, a ModifyRequest, MoveRequest, etc.

        The ASN.1 syntax defined in MEGACO draft 13 has AUTOMATIC TAGS. It
        means that ASN.1 compiler automatically adds tags to SEQUENCE or
        CHOICE components. Therefore, adding implicit tags only confuses
        here. Please see X.680 (12/97) sections 12.3, 24.2, 24.7 - 9, 26.3
        and 28.2.

        Best regards,
                                        Pekka Pessi


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 08:17:48 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02606
	for ; Mon, 31 Jan 2000 08:17:48 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4C63B1E0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 8:15:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15570 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 08:13:19 -0500
Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.08481640@standards.nortelnetworks.com>; Mon, 31 Jan 2000 8:13:19
          -0500
Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com
          [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.2/8.9.3) with SMTP id
          IAA09022; Mon, 31 Jan 2000 08:15:12 -0500 (EST)
Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 85256877.0048CCBC ; Mon, 31 Jan 2000 08:15:10 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <85256877.0048CA51.00@notes950.cc.telcordia.com>
Date:         Mon, 31 Jan 2000 08:16:59 -0500
Reply-To: Selvam Rengasami 
Sender: "Media Gateway Control (megaco)"
              
From: Selvam Rengasami 
Subject:      Re: FW: Re: Stopping of Dial Tone
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

John,

This was also my working assumption and I agree that I don't really see this as
a problem either.

-Selvam Rengasami
Telcordia Technologies

Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com





John Segers  on 01/31/2000 06:33:41 AM

Please respond to John Segers 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Selvam Rengasami/Telcordia)
Subject:  Re: FW: Re: Stopping of Dial Tone




Tom,

Is it really a problem?  The way I always understood this, is that
detection of an event stops an active signal.  It doesn't matter how the
event is detected or reported.  So an event that leads to a partial
match in a digit map (the first digit) would stop dialtone.

Is my thinking flawed?

John

Tom-PT Taylor wrote:
>
> Resend -- first attempt got swallowed.
>
> > -----Original Message-----
> > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > Sent: Wednesday, January 26, 2000 12:46 PM
> > To:   'Megaco'
> > Subject:      Re: Stopping of Dial Tone
> >
> > The problem is real.  The question is what event detection mechanism to
> > use to stop dial tone.  It doesn't matter whether we define a new start of
> > dialling event or simply use the existing dd/* ("detect any DTMF digit"):
> > there is a problem of potential interaction with the digit map.  The most
> > straightforward solution is that the MGC has to ask that the first digit
> > be reported, and only after that it can send down a digit map for
> > everything else.  Alternatively we have to modify section 7.1.8 to make it
> > clear that it is possible to request digit detection in parallel with
> > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> > individual digit events are detected, but the same digits are also
> > processed by the digit map.
> >
> > Comments?
> >
> >
> >                     From:         Madhu Babu 
> >                     Subject:      Stopping of Dial tone
> >
> >
> >                     Hi all,
> >
> >                     According to the example in the Appendix A.1.2 when
> > MGC request
> >                     MG to apply dial tone and check for digit events it is
> > specified
> >                     as
> >
> >                     Events = 2223 {
> >                     al/on, dd/ce {DigitMap=Dialplan0}
> >                     }
> >                     Signals {cg/dt},
> >
> >                     According to the protocol an signal is stopped
> > Whenever any
> >                     event occurs. and here the event requested by MGC is
> > digitmap
> >                     completion,that means dial tone will be stopped when
> > we get
> >                     all the digits (as implied by the name digitmap
> > completion).
> >                     What I suggest is that a new event like
> > "firstdigitcompletion"
> >                     should also  be specified, otherwise how can the first
> > digit itself
> >                     stops the dialtone.
> >
> >                     regards
> >                     -Madhubabu
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

--
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:01:54 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03760
	for ; Mon, 31 Jan 2000 09:01:53 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74CFB0B0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 8:59:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15617 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 08:57:44 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.D6EC0840@standards.nortelnetworks.com>; Mon, 31 Jan 2000 8:47:43
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA19327; Mon, 31 Jan
          2000 08:49:39 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA24153; Mon, 31 Jan
          2000 08:49:39 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 31 Jan 2000 08:46:31 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0C71@whq-msgusr-02.fore.com>
Date:         Mon, 31 Jan 2000 08:49:38 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Non-Buffered EventHandling
X-To:         Bob Lukas 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When EventBuffer is off, any Events are immediately processed against the
current EventsDescriptor.  There is no buffering, and the EventBuffer
descriptor
is not used.

Brian




> -----Original Message-----
> From: Bob Lukas [mailto:blukas@hothaus.com]
> Sent: Friday, January 28, 2000 7:10 PM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Non-Buffered EventHandling
>
>
> The change in text in v14 regarding Event handling has left
> me a little
> confused about event handling when EventBuffer flag is off.
> The text is
> explicit about the EventBuffer=on case, but only says
> "If the EventBuffer flag is off when the new Events
> Descriptor is received,
> the queue is flushed and no events are added to it. The
> default state of
> EventBuffer is off.",
> but section 7.1.5 says
> "The EventBuffer flag specifies whether events are buffered following
> detection of an event in the Events Descriptor, or processed
> immediately".
>
> After a Notify transaction containing ObservedEvents, what
> happens to new
> events detected while EventBuffer is off?
> Are they discarded until a new Events Descriptor is received,
> queued then
> flushed until/when a new Events Descriptor is received, or do
> they continue
> to get matched and reported against the previous Events Descriptor?
> My understanding is that new events would continue to be
> processed as per
> the previous Events Descriptor, correct?
>
> ________________________________
> Bob Lukas
> Broadcom Canada
> Richmond BC
> blukas@broadcom.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:11:43 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03965
	for ; Mon, 31 Jan 2000 09:11:42 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DB5EC450@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:09:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15626 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:08:06 -0500
Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1a) with SMTP id
          <0.47EBD6A0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 8:58:02
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id IAA03609; Mon, 31 Jan 2000 08:59:57
          -0500 (EST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Message-ID:  <200001311359.IAA03609@ietf.org>
Date:         Mon, 31 Jan 2000 08:59:56 -0500
Reply-To: Internet-Drafts@ietf.org
Sender: "Media Gateway Control (megaco)"
              
Comments:     RFC822 error:  Incorrect or incomplete address field found and
              ignored.
From: Internet-Drafts@ietf.org
Subject:      I-D ACTION:draft-ietf-megaco-protocol-05.txt
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Media Gateway Control Working Group of the IETF.

        Title           : MEGACO Protocol
        Author(s)       : F. Cuervo, B. Hill, N. Greene,  C. Huitema,
                          A. Rayhan,  B. Rosen, J. Segers
        Filename        : draft-ietf-megaco-protocol-05.txt
        Pages           : 143
        Date            : 28-Jan-00

MEGACO defines the protocols used between elements of a physically
decomposed multimedia Gateway consisting of a Media Gateway and a Media
Gateway Controller.  There are no functional differences from a system
view between a decomposed gateway, with distributed sub- components
potentially on more than one physical device, and a monolithic gateway.
This document does not define how gateways, multipoint control units or
integrated voice response units (IVRs) work.  Instead it creates a gen-
eral framework that is suitable for these applications.
Packet network interfaces may include IP, ATM or possibly others.  The
interfaces will support a variety of SCN signaling systems, including
tone signaling, ISDN, ISUP, QSIG, and GSM. National variants of these
signaling systems will be supported where applicable.
The protocol definition in this document is common text with ITU Recom-
mendation H.248.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-05.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-ietf-megaco-protocol-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-megaco-protocol-05.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
        access-type="mail-server";
        server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:     <20000128125235.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-megaco-protocol-05.txt

--OtherAccess
Content-Type: Message/External-body;
        name="draft-ietf-megaco-protocol-05.txt";
        site="ftp.ietf.org";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <20000128125235.I-D@ietf.org>

--OtherAccess--

--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:27:07 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04326
	for ; Mon, 31 Jan 2000 09:27:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5D54B40@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:24:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15651 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:23:07 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.630E06E0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:13:07
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA21647; Mon, 31 Jan
          2000 09:15:05 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA29523; Mon, 31 Jan
          2000 09:15:05 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 31 Jan 2000 09:11:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0C77@whq-msgusr-02.fore.com>
Date:         Mon, 31 Jan 2000 09:15:02 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         samittal@hss.hns.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I believe we have not reached consensus on this issue, so I did not
change the text.  Tom, is that your view?

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Monday, January 31, 2000 2:52 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Choosing of ephemeral / physical Termination.
>
>
> The point that "$" is for choosing ephemeral is not yet added
> in V14. Is it that
> the discussion
> is not yet complete? What about foo$ representing choose physical.
>
>
>
>
> Sachin Mittal  on 01/27/2000 11:35:50 AM
>
> Please respond to samittal@hns.com
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Choosing of ephemeral / physical Termination.
>
>
>
>
> Its true that the type of termination should not be
> identified by looking into
> the descriptor
> information. Somewhere in the text this should be added that
> " $ if it appears
> alone indicates
> ephemeral termination and partial $ (ex foo$) indicates
> selection of a physical
> termination
> (a circuit within a trunk group)".
>
>
>
>
> "Rosen, Brian"  on 01/27/2000 02:36:46 AM
>
> Please respond to "Rosen, Brian" 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Choosing of ephemeral / physical Termination.
>
>
>
>
> Generally determined by the "kind" of termination requested.
> Which is in turn, easily discernable from the Media command.
>
> However, upon reflection, I think it's not a good answer.
> I'd propose that we not allow selection of a physical termination,
> in which case choose is always create an ephemeral.  In particular,
> the following is perfectly legal:
> Context=${Add=${}}
> What do you get?
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > Sent: Tuesday, January 25, 2000 9:01 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Choosing of ephemeral / physical Termination.
> >
> >
> > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> > to signal to the MG
> > that it has to create an
> > ephemeral Termination or select an idle physical Termination".
> > How can MG determine when to create an ephemeral termination
> > and when to choose
> > idle physical termination.??
> > What is the logic behind this decision making?
> >
> > regards
> > -Sachin Mittal
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:27:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04328
	for ; Mon, 31 Jan 2000 09:27:07 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6396440@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:24:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15652 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:23:11 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.6566C3F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:13:11
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA21649; Mon, 31 Jan
          2000 09:15:05 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA29525; Mon, 31 Jan
          2000 09:15:05 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 31 Jan 2000 09:11:57 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF1A0C78@whq-msgusr-02.fore.com>
Date:         Mon, 31 Jan 2000 09:15:04 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Command Atomicity
X-To:         samittal@hss.hns.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

At some point, we have to stop holding up release of the document for
changes such as this where a request is made to clarify behavior as
opposed to changing behavior.  I believe that point has already occurred,
but that is for the group to decide.

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@hss.hns.com]
> Sent: Monday, January 31, 2000 3:18 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Cisco SG16: Command Atomicity
>
>
> I think that although MG is dumb and MGC has the full responsiblitiy
> of command sequencing some kind of guidelines should be there for MGC.
> A step in this direction is already taken by moving "Ordering
> of commands"
> to section 9.1 from "transport over IP".
>
> This can include cases like the race condition we discussed
> in this thread
> and may be the following (taken from other thread):
>
> Quote starts................
> > The MGC is responsible for making the state consistent, and this
> > means getting the Subtract through.
> >
> > A termination could be out of service, but still in a context,
> > and would be under failure conditions.  The MGC must run the
> > Subtract command to get the state reasonable.
> >
> > If a command other than Subtract (or ServiceChange) was
> received on a
> > termination that is out of service, an error should be returned.
> End quoted text...........................
>
> One important thing about the above quoted text is that MG is also
> co-operating with MGC for bringing the termination to a
> reasonable state
>
>
>
>
>
>
> "Rosen, Brian"  on 01/29/2000 01:10:03 AM
>
> Please respond to "Rosen, Brian" 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Cisco SG16: Command Atomicity
>
>
>
>
> I have advocated since day one that commands should be atomic.
> Indeed, I believe transactions should be atomic.  I was
> in a minority who believed that backing out of
> a failed transaction a couple of commands in was too hard.
>
> Now we notice that same applies to a command, a couple of
> descriptors in.  If a command is atomic, and it fails, then
> you have to back out of whatever you started, and leave the
> state of the MG the same as it was before you started
> executing the command.
>
> Count me as in favor of atomic commands.
> Of course, count me as in favor of atomic transactions, although
> it's probably easier to back out of a command than a transaction;
> not much easier, but easier.
>
> Note that the text now recommends additional information be
> appended to an error descriptor.  I think codifying such behavior
> is better left for another day; we need more experience before
> we try to write down what ought to be included.
>
> Your specific issue with MOVE's interaction with NOTIFY is
> a little puzzling.  I'm guessing you are worried that
> there is an active EventsDescriptor on a termination, and then
> you MOVE that termination to another context.  The question
> arises, what should occur if the event happens during the processing
> of the MOVE.
>
> This is a kind of race condition.  If the MGC has left itself open
> for such a problem, then it had better not matter to it that it
> could see a Notify from an earlier EventsDescriptor after it sends
> a Move.  If the Move arrived after the Notify was issued, the problem
> is the same as if the Notify were issued in the middle of, or even
> after the Move.
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > Sent: Thursday, January 27, 2000 11:54 PM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Cisco SG16: Command Atomicity
> >
> >
> > This issue has another consequence. For example while
> > processing MOVE command
> > if any event need to be NOTIFIED to MGC, then this notify
> > message need to be
> > delayed
> > till the time response of move is sent. This introduces
> > latency in sending the
> > notify message
> > which by its purpose should not be delayed (MOVE has to tear
> > down old star
> > connection
> > and create a new one in the destination context which may
> take time).
> >
> > Any comments >>>
> >
> >
> >
> >
> >
> >
> > Chip Sharp  on 01/26/2000 05:35:49 AM
> >
> > Please respond to Chip Sharp 
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Cisco SG16:  Command Atomicity
> >
> >
> >
> >
> > Section:        8
> > Category:       Technical, Editorial
> > Issue:          It is unclear if commands are atomic or not.
> > More specifically,
> > if
> > a command contains signals, events or digit map
> descriptors, will they
> > still be applied if the command fails ? If not, should the
> > state of the
> > termination be reset (i.e. clear the signals, events, digit
> > map named in
> > the command that has failed, as in MGCP 0.1) or maintained
> > (i.e. as if the
> > command is not received, as in MGCP 1.0) ?
> > Proposal:       It is recommended that commands are atomic so
> > that failed
> > commands leave the gateway in a well known state. It is furthermore
> > proposed, that a response descriptor should be added to the
> > responses so
> > that if a command fails, the gateway can provide more
> > information to the
> > MGC, rather than just an error code, e.g. for redirection.
> >
> > v13 Status:     OPEN. No relevant text changed.
> >
> >
> > Support NetAid!  http://www.netaid.org
> > --------------------------------------------------
> > Chip Sharp                 Consulting Engineering
> > Cisco Systems              Telco Bio-region
> > Reality - Love it or Leave it.
> > --------------------------------------------------
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:32:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04553
	for ; Mon, 31 Jan 2000 09:32:57 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CE39DEB0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:30:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15707 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:28:38 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.8E0C6D30@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          9:28:38 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 08:29:30 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 09:29:06
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 31 Jan 2000 08:29:03 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Mon, 31 Jan 2000 08:29:04 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Road Map
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Here's my view of where we're going from here to the end of the week.

As everyone is aware, a pile of issues has been raised on the list.  I am in
the process of sorting them out.  I will put out daily progress reports so
we can keep track of what we're doing.

What we should end up with at the end of the week is three documents which
will be input to the SG 16 meeting as Rapporteur's Temporary Documents:

(1) An errata list, indicating clear errors and inconsistencies in the
present H.248(v14) document.

(2) A set of clarifications, which most likely will end up in the H.248
Implementor's Guide.  An open process issue is whether these should be
folded into the Megaco protocol RFC when it comes time to publish it.

(3) A set of missing functionality to be added to H.248 before it is
approved.  Ideally this should be an empty document -- any more
functionality should be saved for the next iteration of the protocol.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:49:10 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05090
	for ; Mon, 31 Jan 2000 09:49:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0C0CFA90@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:46:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15740 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:45:06 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.DA811C40@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          9:45:05 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 08:45:53 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 09:45:43 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LL55H>; Mon, 31 Jan 2000 09:45:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6BF9.D9D3C96C"
Message-ID:  
Date:         Mon, 31 Jan 2000 09:45:41 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6BF9.D9D3C96C
Content-Type: text/plain;
        charset="iso-8859-1"

Right, we haven't converged yet.  I have a suggestion which may resolve
this, that we add these rules

(1) If the MGC provides too little information in an Add command for the MG
to select the bearer type for that termination, the MG must reject the
command with [appropriate error].  In practice, this means either that the
terminationID in the command provides the necessary information, or else
that at least one instance of a Local or Remote descriptor must be present,
containing a c= line with a specified nettype (or the Annex C equivalent).

(2) If the MGC provides too little information in an Add, Move, or Modify
command for the MG to determine the medium to be carried in a given stream,
the MG must reject the command with [appropriate error].  The MG has three
ways to determine medium:
 - streamID unspecified defaults to streamID=1 and medium=audio
 - medium has already been specified for that streamID for another
termination in the same context
 - explicit specification of medium in an m= line (or the Annex C
equivalent) in an instance of Local or Remote for the given streamID.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@FORE.COM]
> Sent: Monday, January 31, 2000 9:15 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Choosing of ephemeral / physical Termination.
>
> I believe we have not reached consensus on this issue, so I did not
> change the text.  Tom, is that your view?
>
> Brian
>
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > Sent: Monday, January 31, 2000 2:52 AM
> > To: MEGACO@standards.nortelnetworks.com
> > Subject: Re: Choosing of ephemeral / physical Termination.
> >
> >
> > The point that "$" is for choosing ephemeral is not yet added
> > in V14. Is it that
> > the discussion
> > is not yet complete? What about foo$ representing choose physical.
> >
> >
> >
> >
> > Sachin Mittal  on 01/27/2000 11:35:50 AM
> >
> > Please respond to samittal@hns.com
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Re: Choosing of ephemeral / physical Termination.
> >
> >
> >
> >
> > Its true that the type of termination should not be
> > identified by looking into
> > the descriptor
> > information. Somewhere in the text this should be added that
> > " $ if it appears
> > alone indicates
> > ephemeral termination and partial $ (ex foo$) indicates
> > selection of a physical
> > termination
> > (a circuit within a trunk group)".
> >
> >
> >
> >
> > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
> >
> > Please respond to "Rosen, Brian" 
> >
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > cc:    (bcc: Sachin Mittal/HSS)
> >
> > Subject:  Re: Choosing of ephemeral / physical Termination.
> >
> >
> >
> >
> > Generally determined by the "kind" of termination requested.
> > Which is in turn, easily discernable from the Media command.
> >
> > However, upon reflection, I think it's not a good answer.
> > I'd propose that we not allow selection of a physical termination,
> > in which case choose is always create an ephemeral.  In particular,
> > the following is perfectly legal:
> > Context=${Add=${}}
> > What do you get?
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> > > Sent: Tuesday, January 25, 2000 9:01 AM
> > > To: MEGACO@standards.nortelnetworks.com
> > > Subject: Choosing of ephemeral / physical Termination.
> > >
> > >
> > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> > > to signal to the MG
> > > that it has to create an
> > > ephemeral Termination or select an idle physical Termination".
> > > How can MG determine when to create an ephemeral termination
> > > and when to choose
> > > idle physical termination.??
> > > What is the logic behind this decision making?
> > >
> > > regards
> > > -Sachin Mittal
> > >
> >

------_=_NextPart_001_01BF6BF9.D9D3C96C
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Choosing of ephemeral / physical Termination.




        Right, we haven't =
converged yet.  I have a suggestion which may resolve this, that =
we add these rules

        


        (1) If the MGC =
provides too little information in an Add command for the MG to select =
the bearer type for that termination, the MG must reject the command =
with [appropriate error].  In practice, this means either that the =
terminationID in the command provides the necessary information, or =
else that at least one instance of a Local or Remote descriptor must be =
present, containing a c=3D line with a specified nettype (or the Annex =
C equivalent).
        


        (2) If the MGC =
provides too little information in an Add, Move, or Modify command for =
the MG to determine the medium to be carried in a given stream, the MG =
must reject the command with [appropriate error].  The MG has =
three ways to determine medium:
        


         - streamID =
unspecified defaults to streamID=3D1 and medium=3Daudio

         - medium has =
already been specified for that streamID for another termination in the =
same context

         - explicit =
specification of medium in an m=3D line (or the Annex C equivalent) in =
an instance of Local or Remote for the given streamID.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          Sent:   Monday, January 31, 2000 9:15 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Choosing of ephemeral / physical =
Termination.

          


          I believe we have not reached =
consensus on this issue, so I did not

          change the text.  Tom, is that =
your view?

          


          Brian

          


          > -----Original Message-----

          > From: Sachin Mittal =
[mailto:samittal@hss.hns.com]

          > Sent: Monday, January 31, 2000 =
2:52 AM

          > To: =
MEGACO@standards.nortelnetworks.com

          > Subject: Re: Choosing of =
ephemeral / physical Termination.

          >

          >

          > The point that "$" is =
for choosing ephemeral is not yet added

          > in V14. Is it that

          > the discussion

          > is not yet complete? What about =
foo$ representing choose physical.

          >

          >

          >

          >

          > Sachin Mittal =
<samittal@hns.com> on 01/27/2000 11:35:50 AM

          >

          > Please respond to =
samittal@hns.com

          >

          > To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          > cc:    (bcc: =
Sachin Mittal/HSS)

          >

          > Subject:  Re: Choosing of =
ephemeral / physical Termination.

          >

          >

          >

          >

          > Its true that the type of =
termination should not be

          > identified by looking =
into

          > the descriptor

          > information. Somewhere in the =
text this should be added that

          > " $ if it appears

          > alone indicates

          > ephemeral termination and =
partial $ (ex foo$) indicates

          > selection of a physical

          > termination

          > (a circuit within a trunk =
group)".

          >

          >

          >

          >

          > "Rosen, Brian" =
<brosen@FORE.COM> on 01/27/2000 02:36:46 AM

          >

          > Please respond to "Rosen, =
Brian" <brosen@FORE.COM>

          >

          > To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          > cc:    (bcc: =
Sachin Mittal/HSS)

          >

          > Subject:  Re: Choosing of =
ephemeral / physical Termination.

          >

          >

          >

          >

          > Generally determined by the =
"kind" of termination requested.

          > Which is in turn, easily =
discernable from the Media command.

          >

          > However, upon reflection, I =
think it's not a good answer.

          > I'd propose that we not allow =
selection of a physical termination,

          > in which case choose is always =
create an ephemeral.  In particular,

          > the following is perfectly =
legal:

          > Context=3D${Add=3D${}}

          > What do you get?

          >

          > Brian

          >

          > > -----Original =
Message-----

          > > From: Sachin Mittal =
[mailto:samittal@hss.hns.com]

          > > Sent: Tuesday, January 25, =
2000 9:01 AM

          > > To: =
MEGACO@standards.nortelnetworks.com

          > > Subject: Choosing of =
ephemeral / physical Termination.

          > >

          > >

          > > Annex B.1 says that =
"The CHOOSE TerminationID $ may be used

          > > to signal to the MG

          > > that it has to create =
an

          > > ephemeral Termination or =
select an idle physical Termination".

          > > How can MG determine when =
to create an ephemeral termination

          > > and when to choose

          > > idle physical =
termination.??

          > > What is the logic behind =
this decision making?

          > >

          > > regards

          > > -Sachin Mittal

          > >

          >

          

        


------_=_NextPart_001_01BF6BF9.D9D3C96C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:56:25 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05480
	for ; Mon, 31 Jan 2000 09:56:24 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.083E70F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:53:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15774 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:51:39 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C5056D20@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          9:51:39 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 08:52:39 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 09:52:17
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 31 Jan 2000 08:52:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6BFA.C17929C4"
Message-ID:  
Date:         Mon, 31 Jan 2000 08:52:12 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: FW: Re: Stopping of Dial Tone
X-To:         Selvam Rengasami 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6BFA.C17929C4
Content-Type: text/plain;
        charset="ISO-8859-1"

I'm happy to accept this as the common understanding.

> -----Original Message-----
> From: Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> Sent: Monday, January 31, 2000 8:17 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: FW: Re: Stopping of Dial Tone
>
> John,
>
> This was also my working assumption and I agree that I don't really see
> this as
> a problem either.
>
> -Selvam Rengasami
> Telcordia Technologies
>
> Tel:  +1 732 758 5260
> E-mail:  srengasa@telcordia.com
>
>
>
>
>
> John Segers  on 01/31/2000 06:33:41 AM
>
> Please respond to John Segers 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Selvam Rengasami/Telcordia)
> Subject:  Re: FW: Re: Stopping of Dial Tone
>
>
>
>
> Tom,
>
> Is it really a problem?  The way I always understood this, is that
> detection of an event stops an active signal.  It doesn't matter how the
> event is detected or reported.  So an event that leads to a partial
> match in a digit map (the first digit) would stop dialtone.
>
> Is my thinking flawed?
>
> John
>
> Tom-PT Taylor wrote:
> >
> > Resend -- first attempt got swallowed.
> >
> > > -----Original Message-----
> > > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > > Sent: Wednesday, January 26, 2000 12:46 PM
> > > To:   'Megaco'
> > > Subject:      Re: Stopping of Dial Tone
> > >
> > > The problem is real.  The question is what event detection mechanism
> to
> > > use to stop dial tone.  It doesn't matter whether we define a new
> start of
> > > dialling event or simply use the existing dd/* ("detect any DTMF
> digit"):
> > > there is a problem of potential interaction with the digit map.  The
> most
> > > straightforward solution is that the MGC has to ask that the first
> digit
> > > be reported, and only after that it can send down a digit map for
> > > everything else.  Alternatively we have to modify section 7.1.8 to
> make it
> > > clear that it is possible to request digit detection in parallel with
> > > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> > > individual digit events are detected, but the same digits are also
> > > processed by the digit map.
> > >
> > > Comments?
> > >
> > >
> > >                     From:         Madhu Babu 
> > >                     Subject:      Stopping of Dial tone
> > >
> > >
> > >                     Hi all,
> > >
> > >                     According to the example in the Appendix A.1.2
> when
> > > MGC request
> > >                     MG to apply dial tone and check for digit events
> it is
> > > specified
> > >                     as
> > >
> > >                     Events = 2223 {
> > >                     al/on, dd/ce {DigitMap=Dialplan0}
> > >                     }
> > >                     Signals {cg/dt},
> > >
> > >                     According to the protocol an signal is stopped
> > > Whenever any
> > >                     event occurs. and here the event requested by MGC
> is
> > > digitmap
> > >                     completion,that means dial tone will be stopped
> when
> > > we get
> > >                     all the digits (as implied by the name digitmap
> > > completion).
> > >                     What I suggest is that a new event like
> > > "firstdigitcompletion"
> > >                     should also  be specified, otherwise how can the
> first
> > > digit itself
> > >                     stops the dialtone.
> > >
> > >                     regards
> > >                     -Madhubabu
> > >
> > > Tom Taylor
> > > Advisor -- IPConnect Standards
> > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > > Phone and FAX: +1 613 736 0961
> > >
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

------_=_NextPart_001_01BF6BFA.C17929C4
Content-Type: text/html;
        charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: FW: Re: Stopping of Dial Tone




        I'm happy to accept =
this as the common understanding.

        

          

          -----Original Message-----

          From:   Selvam Rengasami =
[SMTP:srengasa@TELCORDIA.COM]

          Sent:   Monday, January 31, 2000 8:17 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: FW: Re: Stopping of Dial =
Tone

          


          John,

          


          This was also my working assumption =
and I agree that I don't really see this as

          a problem either.

          


          -Selvam Rengasami

          Telcordia Technologies

          


          Tel:  +1 732 758 5260

          E-mail:  =
srengasa@telcordia.com

          

          

          

          

          


          John Segers <jsegers@LUCENT.COM> =
on 01/31/2000 06:33:41 AM

          


          Please respond to John Segers =
<jsegers@LUCENT.COM>

          


          To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          cc:    (bcc: Selvam =
Rengasami/Telcordia)

          Subject:  Re: FW: Re: Stopping =
of Dial Tone

          

          

          

          


          Tom,

          


          Is it really a problem?  The way =
I always understood this, is that

          detection of an event stops an active =
signal.  It doesn't matter how the

          event is detected or reported.  =
So an event that leads to a partial

          match in a digit map (the first =
digit) would stop dialtone.

          


          Is my thinking flawed?

          


          John

          


          Tom-PT Taylor wrote:

          >

          > Resend -- first attempt got =
swallowed.

          >

          > > -----Original =
Message-----

          > > From: Taylor, Tom-PT =
[CAR:B904:EXCH]

          > > Sent: Wednesday, January =
26, 2000 12:46 PM

          > > To:   =
'Megaco'

          > > =
Subject:      Re: Stopping of Dial Tone

          > >

          > > The problem is real.  =
The question is what event detection mechanism to

          > > use to stop dial =
tone.  It doesn't matter whether we define a new start of

          > > dialling event or simply =
use the existing dd/* ("detect any DTMF digit"):

          > > there is a problem of =
potential interaction with the digit map.  The most

          > > straightforward solution is =
that the MGC has to ask that the first digit

          > > be reported, and only after =
that it can send down a digit map for

          > > everything else.  =
Alternatively we have to modify section 7.1.8 to make it

          > > clear that it is possible =
to request digit detection in parallel with

          > > digit mapping (i.e. dd/* in =
combination with dd/ce {...} means that

          > > individual digit events are =
detected, but the same digits are also

          > > processed by the digit =
map.

          > >

          > > Comments?

          > >

          > >

          > =
>           &n=
bsp;         =
From:         Madhu Babu =
<bmbabu@HSS.HNS.COM>

          > =
>           &n=
bsp;         =
Subject:      Stopping of Dial tone

          > >

          > >

          > =
>           &n=
bsp;         Hi all,

          > >

          > =
>           &n=
bsp;         According to the =
example in the Appendix A.1.2 when

          > > MGC request

          > =
>           &n=
bsp;         MG to apply dial =
tone and check for digit events it is

          > > specified

          > =
>           &n=
bsp;         as

          > >

          > =
>           &n=
bsp;         Events =3D 2223 =
{

          > =
>           &n=
bsp;         al/on, dd/ce =
{DigitMap=3DDialplan0}

          > =
>           &n=
bsp;         }

          > =
>           &n=
bsp;         Signals =
{cg/dt},

          > >

          > =
>           &n=
bsp;         According to the =
protocol an signal is stopped

          > > Whenever any

          > =
>           &n=
bsp;         event occurs. and =
here the event requested by MGC is

          > > digitmap

          > =
>           &n=
bsp;         completion,that =
means dial tone will be stopped when

          > > we get

          > =
>           &n=
bsp;         all the digits (as =
implied by the name digitmap

          > > completion).

          > =
>           &n=
bsp;         What I suggest is =
that a new event like

          > > =
"firstdigitcompletion"

          > =
>           &n=
bsp;         should also  =
be specified, otherwise how can the first

          > > digit itself

          > =
>           &n=
bsp;         stops the =
dialtone.

          > >

          > =
>           &n=
bsp;         regards

          > =
>           &n=
bsp;         -Madhubabu

          > >

          > > Tom Taylor

          > > Advisor -- IPConnect =
Standards

          > > E-mail: =
taylor@nortelnetworks.com (internally, Tom-PT Taylor)

          > > Phone and FAX: +1 613 736 =
0961

          > >

          


          --

          John =
Segers           =
            =
           email: =
jsegers@lucent.com

          Lucent =
Technologies          =
            =
            =
      Room HE 306

          Dept. Forward Looking =
Work           &n=
bsp;          phone: +31 =
35 687 4724

          P.O. Box 18, 1270 AA  =
Huizen           =
           fax: +31 =
35 687 5954

          

        


------_=_NextPart_001_01BF6BFA.C17929C4--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 09:56:26 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05482
	for ; Mon, 31 Jan 2000 09:56:25 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08A9B5E0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 9:53:32 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15781 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 09:53:22 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.027F5760@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          9:53:22 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 08:55:14 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 09:54:56
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 31 Jan 2000 08:54:53 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6BFB.2119FB9C"
Message-ID:  
Date:         Mon, 31 Jan 2000 08:54:54 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Telcordia SG 16: Updates to References Section of H.248
X-To:         John Segers 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6BFB.2119FB9C
Content-Type: text/plain

OK, in the interests of common alignment, I will remark that until we have
defined (in packages) the SDP to carry the information equivalent of every
field in Annex C, we have a disconnect between the two encodings.  Lots of
work to do ...

> -----Original Message-----
> From: John Segers [SMTP:jsegers@LUCENT.COM]
> Sent: Monday, January 31, 2000 6:54 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Telcordia SG 16: Updates to References Section of H.248
>
> Tom,
>
> The reference section has been updated in the new draft.
>
> Your remark that Annex C is SG 16's business puzzles me.  It seems to
> imply that IETF is developing a text protocol and ITU a binary protocol,
> while in actual fact, the two organizations are working on a joint
> protocol with two encoding options.  It is up to the editors (both ITU
> and IETF) to keep the two options aligned.
>
> Comments about problems being the other groups's business do not support
> this mode of operation.
>
> Cheers,
>
> John
>
> > Tom-PT Taylor wrote:
> >
> > Agreed.  Not sure why SG 16 is doing this to themselves, but Annex C
> > is their business.
> >
> >      -----Original Message-----
> >      From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
> >      Sent:   Thursday, January 27, 2000 8:52 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Telcordia SG 16: Updates to References Section of
> >      H.248
> >
> >      The documents referenced in Annex C of H.248 (e.g., Q.763) should
> >      be added as
> >      normative references as they are needed to implement the
> >      protocol.
> >
> >      Specifically, the following should be added as normative
> >      references since they
> >      are needed to implement the protocol of Annex C:
> >
> >      Q.1901  (informally known as Q.BICC)
> >
> >      Q.763-1999  (ISUP)
> >
> >      Q.2630  (AAL2 Signaling)
> >
> >      Q.2931  (B-ISDN Network Access Layer Signaling)
> >
> >      Q.2941.3  (Generic Identifier Transport
> >      ? Extensions for BICC)
> >
> >      Q.931-1998 (N-ISDN Network Access Layer Signaling)
> >
> >      In addition, the reference to Q.931 in the Informative References
> >      section should
> >      be removed since it is being added to the Normative references
> >      section.
> >
> >      Section 3.1 of a Telcordia Technologies contribution to SG 16
> >      (which can be
> >      found at
> >
> ftp://standard.pictel.com/avc-site/Incoming/telcordia-h248-misc-cmts.DOC
> >      )
> >      provides a proposal for updating the references.
> >
> >      -Selvam Rengasami
> >      Telcordia Technologies
> >      Tel:  +1 732 758 5260
> >      E-mail:  srengasa@telcordia.com
>
> --
> John Segers                                  email: jsegers@lucent.com
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

------_=_NextPart_001_01BF6BFB.2119FB9C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Telcordia SG 16: Updates to References Section of =
H.248




        OK, in the interests =
of common alignment, I will remark that until we have defined (in =
packages) the SDP to carry the information equivalent of every field in =
Annex C, we have a disconnect between the two encodings.  Lots of =
work to do ...
        

          

          -----Original Message-----

          From:   John Segers [SMTP:jsegers@LUCENT.COM]

          Sent:   Monday, January 31, 2000 6:54 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Telcordia SG 16: Updates to =
References Section of H.248

          


          Tom,

          


          The reference section has been updated =
in the new draft.

          


          Your remark that Annex C is SG 16's =
business puzzles me.  It seems to

          imply that IETF is developing a text =
protocol and ITU a binary protocol,

          while in actual fact, the two =
organizations are working on a joint

          protocol with two encoding =
options.  It is up to the editors (both ITU

          and IETF) to keep the two options =
aligned.

          


          Comments about problems being the =
other groups's business do not support

          this mode of operation.

          


          Cheers,

          


          John

          


          > Tom-PT Taylor wrote:

          >

          > Agreed.  Not sure why SG 16 =
is doing this to themselves, but Annex C

          > is their business.

          >

          >      =
-----Original Message-----

          >      =
From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]

          >      =
Sent:   Thursday, January 27, 2000 8:52 AM

          >      =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          >      =
Subject:        Telcordia SG 16: =
Updates to References Section of

          >      =
H.248

          >

          >      =
The documents referenced in Annex C of H.248 (e.g., Q.763) =
should

          >      be =
added as

          >      =
normative references as they are needed to implement the

          >      =
protocol.

          >

          >      =
Specifically, the following should be added as normative

          >      =
references since they

          >      =
are needed to implement the protocol of Annex C:

          >

          >      =
Q.1901  (informally known as Q.BICC)

          >

          >      =
Q.763-1999  (ISUP)

          >

          >      =
Q.2630  (AAL2 Signaling)

          >

          >      =
Q.2931  (B-ISDN Network Access Layer Signaling)

          >

          >      =
Q.2941.3  (Generic Identifier Transport

          >      ? =
Extensions for BICC)

          >

          >      =
Q.931-1998 (N-ISDN Network Access Layer Signaling)

          >

          >      In =
addition, the reference to Q.931 in the Informative References

          >      =
section should

          >      be =
removed since it is being added to the Normative references

          >      =
section.

          >

          >      =
Section 3.1 of a Telcordia Technologies contribution to SG 16

          >      =
(which can be

          >      =
found at

          >      =
ftp://standard.pictel.com/avc-site/Incoming/telcordia-=
h248-misc-cmts.DOC

          >      =
)

          >      =
provides a proposal for updating the references.

          >

          >      =
-Selvam Rengasami

          >      =
Telcordia Technologies

          >      =
Tel:  +1 732 758 5260

          >      =
E-mail:  srengasa@telcordia.com

          


          --

          John =
Segers           =
            =
           email: =
jsegers@lucent.com

          Lucent =
Technologies          =
            =
            =
      Room HE 306

          Dept. Forward Looking =
Work           &n=
bsp;          phone: +31 =
35 687 4724

          P.O. Box 18, 1270 AA  =
Huizen           =
           fax: +31 =
35 687 5954

          

        


------_=_NextPart_001_01BF6BFB.2119FB9C--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 10:39:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07557
	for ; Mon, 31 Jan 2000 10:39:18 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10679DF0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 10:36:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15873 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 10:34:42 -0500
Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.628FCAA0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          10:24:41 -0500
Received: from elb1 (elb1.al.edt.ericsson.se [136.225.252.11]) by
          penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with SMTP id
          QAA08299; Mon, 31 Jan 2000 16:26:41 +0100 (MET)
Received: from elb4.al.edt.ericsson.se by elb1 (SMI-8.6/LME-2.2.6) id QAA00015;
          Mon, 31 Jan 2000 16:26:40 +0100
Received: from ericsson.com ([147.214.68.19]) by elb4.al.edt.ericsson.se
          (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id QAA04263; Mon, 31 Jan 2000
          16:26:39 +0100 (MET)
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3895A9B0.B525A636@ericsson.com>
Date:         Mon, 31 Jan 2000 16:26:40 +0100
Reply-To: Christian Groves 
Sender: "Media Gateway Control (megaco)"
              
From: Christian Groves 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-cc:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hello all,

I believe that we have diverged from the first email in this thread. We
do not need rules to determine what media and bearer is instantiated.

For a physical termination a certain terminationID schema will be
assigned by the MG. ie. /myscheme/physical/trunk/circuit
If the MGC wanted to CHOOSE a physical termination it could either
wildcard 'trunk' or 'circuit'.

For a emphemeral terminatoion a certain terminationID schema will be
assigned by the MG. The MGC by various means would be aware of this
scheme.
ie. /myscheme/euphemeral/IP
If the MGC wanted to CHOOSE a euphemeral termination it could wilcard
the 'IP'

The 'physical' and 'ephemeral' could be anything in the the MG assigned
scheme that would differentiate the two.

If the MGC doesn't care which one then it CHOOSES on the
'ephemeral'/'physical' level. The MG can determine which one to return
from ANY information in the media descriptors. This is something for the
MG to decide, not something that needs to be specified in rules in H248
because they'll probably change according to your application, resource
allocation algorithms in the MG, etc. I do agree that an error should be
returned if the MG cannot determine the terminationID.

I think the scope of this is also limited to the ADD command. The ADD
will return a fully specified terminationID which can then be referenced
in Move, Modify, Subtract etc.

Regards, Christian

Tom-PT Taylor wrote:
>
> Right, we haven't converged yet.  I have a suggestion which may
> resolve this, that we add these rules
>
> (1) If the MGC provides too little information in an Add command for
> the MG to select the bearer type for that termination, the MG must
> reject the command with [appropriate error].  In practice, this means
> either that the terminationID in the command provides the necessary
> information, or else that at least one instance of a Local or Remote
> descriptor must be present, containing a c= line with a specified
> nettype (or the Annex C equivalent).
>
> (2) If the MGC provides too little information in an Add, Move, or
> Modify command for the MG to determine the medium to be carried in a
> given stream, the MG must reject the command with [appropriate
> error].  The MG has three ways to determine medium:
>
>  - streamID unspecified defaults to streamID=1 and medium=audio
>  - medium has already been specified for that streamID for another
> termination in the same context
>  - explicit specification of medium in an m= line (or the Annex C
> equivalent) in an instance of Local or Remote for the given streamID.
>
>      -----Original Message-----
>      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
>      Sent:   Monday, January 31, 2000 9:15 AM
>      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:        Re: Choosing of ephemeral / physical Termination.
>
>      I believe we have not reached consensus on this issue, so I did
>      not
>      change the text.  Tom, is that your view?
>
>      Brian
>
>      > -----Original Message-----
>      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>      > Sent: Monday, January 31, 2000 2:52 AM
>      > To: MEGACO@standards.nortelnetworks.com
>      > Subject: Re: Choosing of ephemeral / physical Termination.
>      >
>      >
>      > The point that "$" is for choosing ephemeral is not yet added
>      > in V14. Is it that
>      > the discussion
>      > is not yet complete? What about foo$ representing choose
>      physical.
>      >
>      >
>      >
>      >
>      > Sachin Mittal  on 01/27/2000 11:35:50 AM
>      >
>      > Please respond to samittal@hns.com
>      >
>      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > cc:    (bcc: Sachin Mittal/HSS)
>      >
>      > Subject:  Re: Choosing of ephemeral / physical Termination.
>      >
>      >
>      >
>      >
>      > Its true that the type of termination should not be
>      > identified by looking into
>      > the descriptor
>      > information. Somewhere in the text this should be added that
>      > " $ if it appears
>      > alone indicates
>      > ephemeral termination and partial $ (ex foo$) indicates
>      > selection of a physical
>      > termination
>      > (a circuit within a trunk group)".
>      >
>      >
>      >
>      >
>      > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
>      >
>      > Please respond to "Rosen, Brian" 
>      >
>      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > cc:    (bcc: Sachin Mittal/HSS)
>      >
>      > Subject:  Re: Choosing of ephemeral / physical Termination.
>      >
>      >
>      >
>      >
>      > Generally determined by the "kind" of termination requested.
>      > Which is in turn, easily discernable from the Media command.
>      >
>      > However, upon reflection, I think it's not a good answer.
>      > I'd propose that we not allow selection of a physical
>      termination,
>      > in which case choose is always create an ephemeral.  In
>      particular,
>      > the following is perfectly legal:
>      > Context=${Add=${}}
>      > What do you get?
>      >
>      > Brian
>      >
>      > > -----Original Message-----
>      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
>      > > Sent: Tuesday, January 25, 2000 9:01 AM
>      > > To: MEGACO@standards.nortelnetworks.com
>      > > Subject: Choosing of ephemeral / physical Termination.
>      > >
>      > >
>      > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
>      > > to signal to the MG
>      > > that it has to create an
>      > > ephemeral Termination or select an idle physical
>      Termination".
>      > > How can MG determine when to create an ephemeral termination
>      > > and when to choose
>      > > idle physical termination.??
>      > > What is the logic behind this decision making?
>      > >
>      > > regards
>      > > -Sachin Mittal
>      > >
>      >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 11:02:36 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08231
	for ; Mon, 31 Jan 2000 11:02:32 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.49C2D0D0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 10:59:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15942 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 10:57:49 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.03022CE0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          10:57:48 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 09:59:21 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 10:58:59 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LL9CL>; Mon, 31 Jan 2000 10:58:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C04.15D55156"
Message-ID:  
Date:         Mon, 31 Jan 2000 10:58:52 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C04.15D55156
Content-Type: text/plain;
        charset="iso-8859-1"

I don't think we are disagreeing here.  My proposed rules are clarifications
of the current situation -- if anything, they would go into an Implementor's
guide, but maybe they are obvious enough that there's no need to state them.

> -----Original Message-----
> From: Christian Groves [SMTP:Christian.Groves@ericsson.com]
> Sent: Monday, January 31, 2000 10:27 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Cc:   Taylor, Tom-PT [CAR:B904:EXCH]
> Subject:      Re: Choosing of ephemeral / physical Termination.
>
> Hello all,
>
> I believe that we have diverged from the first email in this thread. We
> do not need rules to determine what media and bearer is instantiated.
>
> For a physical termination a certain terminationID schema will be
> assigned by the MG. ie. /myscheme/physical/trunk/circuit
> If the MGC wanted to CHOOSE a physical termination it could either
> wildcard 'trunk' or 'circuit'.
>
> For a emphemeral terminatoion a certain terminationID schema will be
> assigned by the MG. The MGC by various means would be aware of this
> scheme.
> ie. /myscheme/euphemeral/IP
> If the MGC wanted to CHOOSE a euphemeral termination it could wilcard
> the 'IP'
>
> The 'physical' and 'ephemeral' could be anything in the the MG assigned
> scheme that would differentiate the two.
>
> If the MGC doesn't care which one then it CHOOSES on the
> 'ephemeral'/'physical' level. The MG can determine which one to return
> from ANY information in the media descriptors. This is something for the
> MG to decide, not something that needs to be specified in rules in H248
> because they'll probably change according to your application, resource
> allocation algorithms in the MG, etc. I do agree that an error should be
> returned if the MG cannot determine the terminationID.
>
> I think the scope of this is also limited to the ADD command. The ADD
> will return a fully specified terminationID which can then be referenced
> in Move, Modify, Subtract etc.
>
> Regards, Christian
>
> Tom-PT Taylor wrote:
> >
> > Right, we haven't converged yet.  I have a suggestion which may
> > resolve this, that we add these rules
> >
> > (1) If the MGC provides too little information in an Add command for
> > the MG to select the bearer type for that termination, the MG must
> > reject the command with [appropriate error].  In practice, this means
> > either that the terminationID in the command provides the necessary
> > information, or else that at least one instance of a Local or Remote
> > descriptor must be present, containing a c= line with a specified
> > nettype (or the Annex C equivalent).
> >
> > (2) If the MGC provides too little information in an Add, Move, or
> > Modify command for the MG to determine the medium to be carried in a
> > given stream, the MG must reject the command with [appropriate
> > error].  The MG has three ways to determine medium:
> >
> >  - streamID unspecified defaults to streamID=1 and medium=audio
> >  - medium has already been specified for that streamID for another
> > termination in the same context
> >  - explicit specification of medium in an m= line (or the Annex C
> > equivalent) in an instance of Local or Remote for the given streamID.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Monday, January 31, 2000 9:15 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Re: Choosing of ephemeral / physical Termination.
> >
> >      I believe we have not reached consensus on this issue, so I did
> >      not
> >      change the text.  Tom, is that your view?
> >
> >      Brian
> >
> >      > -----Original Message-----
> >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > Sent: Monday, January 31, 2000 2:52 AM
> >      > To: MEGACO@standards.nortelnetworks.com
> >      > Subject: Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      > The point that "$" is for choosing ephemeral is not yet added
> >      > in V14. Is it that
> >      > the discussion
> >      > is not yet complete? What about foo$ representing choose
> >      physical.
> >      >
> >      >
> >      >
> >      >
> >      > Sachin Mittal  on 01/27/2000 11:35:50 AM
> >      >
> >      > Please respond to samittal@hns.com
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Its true that the type of termination should not be
> >      > identified by looking into
> >      > the descriptor
> >      > information. Somewhere in the text this should be added that
> >      > " $ if it appears
> >      > alone indicates
> >      > ephemeral termination and partial $ (ex foo$) indicates
> >      > selection of a physical
> >      > termination
> >      > (a circuit within a trunk group)".
> >      >
> >      >
> >      >
> >      >
> >      > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
> >      >
> >      > Please respond to "Rosen, Brian" 
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Generally determined by the "kind" of termination requested.
> >      > Which is in turn, easily discernable from the Media command.
> >      >
> >      > However, upon reflection, I think it's not a good answer.
> >      > I'd propose that we not allow selection of a physical
> >      termination,
> >      > in which case choose is always create an ephemeral.  In
> >      particular,
> >      > the following is perfectly legal:
> >      > Context=${Add=${}}
> >      > What do you get?
> >      >
> >      > Brian
> >      >
> >      > > -----Original Message-----
> >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> >      > > To: MEGACO@standards.nortelnetworks.com
> >      > > Subject: Choosing of ephemeral / physical Termination.
> >      > >
> >      > >
> >      > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >      > > to signal to the MG
> >      > > that it has to create an
> >      > > ephemeral Termination or select an idle physical
> >      Termination".
> >      > > How can MG determine when to create an ephemeral termination
> >      > > and when to choose
> >      > > idle physical termination.??
> >      > > What is the logic behind this decision making?
> >      > >
> >      > > regards
> >      > > -Sachin Mittal
> >      > >
> >      >

------_=_NextPart_001_01BF6C04.15D55156
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Choosing of ephemeral / physical Termination.




        I don't think we are =
disagreeing here.  My proposed rules are clarifications of the =
current situation -- if anything, they would go into an Implementor's =
guide, but maybe they are obvious enough that there's no need to state =
them.
        

          

          -----Original Message-----

          From:   Christian Groves =
[SMTP:Christian.Groves@ericsson.com]

          Sent:   Monday, January 31, 2000 10:27 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Cc:     Taylor, Tom-PT [CAR:B904:EXCH]

          Subject:       =
 Re: Choosing of ephemeral / physical =
Termination.

          


          Hello all,

          


          I believe that we have diverged from =
the first email in this thread. We

          do not need rules to determine what =
media and bearer is instantiated.

          


          For a physical termination a certain =
terminationID schema will be

          assigned by the MG. ie. =
/myscheme/physical/trunk/circuit 

          If the MGC wanted to CHOOSE a =
physical termination it could either

          wildcard 'trunk' or 'circuit'. =


          


          For a emphemeral terminatoion a =
certain terminationID schema will be

          assigned by the MG. The MGC by =
various means would be aware of this

          scheme.

          ie. /myscheme/euphemeral/IP

          If the MGC wanted to CHOOSE a =
euphemeral termination it could wilcard

          the 'IP'

          


          The 'physical' and 'ephemeral' could =
be anything in the the MG assigned

          scheme that would differentiate the =
two. 

          


          If the MGC doesn't care which one then =
it CHOOSES on the

          'ephemeral'/'physical' level. The MG =
can determine which one to return

          from ANY information in the media =
descriptors. This is something for the

          MG to decide, not something that =
needs to be specified in rules in H248

          because they'll probably change =
according to your application, resource

          allocation algorithms in the MG, etc. =
I do agree that an error should be

          returned if the MG cannot determine =
the terminationID.

          


          I think the scope of this is also =
limited to the ADD command. The ADD

          will return a fully specified =
terminationID which can then be referenced

          in Move, Modify, Subtract etc.

          


          Regards, Christian

          


          Tom-PT Taylor wrote:

          > 

          > Right, we haven't converged =
yet.  I have a suggestion which may

          > resolve this, that we add these =
rules

          > 

          > (1) If the MGC provides too =
little information in an Add command for

          > the MG to select the bearer type =
for that termination, the MG must

          > reject the command with =
[appropriate error].  In practice, this means

          > either that the terminationID in =
the command provides the necessary

          > information, or else that at =
least one instance of a Local or Remote

          > descriptor must be present, =
containing a c=3D line with a specified

          > nettype (or the Annex C =
equivalent).

          > 

          > (2) If the MGC provides too =
little information in an Add, Move, or

          > Modify command for the MG to =
determine the medium to be carried in a

          > given stream, the MG must reject =
the command with [appropriate

          > error].  The MG has three =
ways to determine medium:

          > 

          >  - streamID unspecified =
defaults to streamID=3D1 and medium=3Daudio

          >  - medium has already been =
specified for that streamID for another

          > termination in the same =
context

          >  - explicit specification =
of medium in an m=3D line (or the Annex C

          > equivalent) in an instance of =
Local or Remote for the given streamID.

          > 

          >      =
-----Original Message-----

          >      =
From:   Rosen, Brian [SMTP:brosen@FORE.COM]

          >      =
Sent:   Monday, January 31, 2000 9:15 AM

          >      =
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          >      =
Subject:        Re: Choosing of =
ephemeral / physical Termination.

          > 

          >      I =
believe we have not reached consensus on this issue, so I did

          >      =
not

          >      =
change the text.  Tom, is that your view?

          > 

          >      =
Brian

          > 

          >      =
> -----Original Message-----

          >      =
> From: Sachin Mittal [mailto:samittal@hss.hns.com]

          >      =
> Sent: Monday, January 31, 2000 2:52 AM

          >      =
> To: MEGACO@standards.nortelnetworks.com

          >      =
> Subject: Re: Choosing of ephemeral / physical Termination.

          >      =
>

          >      =
>

          >      =
> The point that "$" is for choosing ephemeral is not yet =
added

          >      =
> in V14. Is it that

          >      =
> the discussion

          >      =
> is not yet complete? What about foo$ representing choose

          >      =
physical.

          >      =
>

          >      =
>

          >      =
>

          >      =
>

          >      =
> Sachin Mittal <samittal@hns.com> on 01/27/2000 11:35:50 =
AM

          >      =
>

          >      =
> Please respond to samittal@hns.com

          >      =
>

          >      =
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM

          >      =
> cc:    (bcc: Sachin Mittal/HSS)

          >      =
>

          >      =
> Subject:  Re: Choosing of ephemeral / physical =
Termination.

          >      =
>

          >      =
>

          >      =
>

          >      =
>

          >      =
> Its true that the type of termination should not be

          >      =
> identified by looking into

          >      =
> the descriptor

          >      =
> information. Somewhere in the text this should be added =
that

          >      =
> " $ if it appears

          >      =
> alone indicates

          >      =
> ephemeral termination and partial $ (ex foo$) indicates

          >      =
> selection of a physical

          >      =
> termination

          >      =
> (a circuit within a trunk group)".

          >      =
>

          >      =
>

          >      =
>

          >      =
>

          >      =
> "Rosen, Brian" <brosen@FORE.COM> on 01/27/2000 =
02:36:46 AM

          >      =
>

          >      =
> Please respond to "Rosen, Brian" =
<brosen@FORE.COM>

          >      =
>

          >      =
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM

          >      =
> cc:    (bcc: Sachin Mittal/HSS)

          >      =
>

          >      =
> Subject:  Re: Choosing of ephemeral / physical =
Termination.

          >      =
>

          >      =
>

          >      =
>

          >      =
>

          >      =
> Generally determined by the "kind" of termination =
requested.

          >      =
> Which is in turn, easily discernable from the Media =
command.

          >      =
>

          >      =
> However, upon reflection, I think it's not a good answer.

          >      =
> I'd propose that we not allow selection of a physical

          >      =
termination,

          >      =
> in which case choose is always create an ephemeral.  =
In

          >      =
particular,

          >      =
> the following is perfectly legal:

          >      =
> Context=3D${Add=3D${}}

          >      =
> What do you get?

          >      =
>

          >      =
> Brian

          >      =
>

          >      =
> > -----Original Message-----

          >      =
> > From: Sachin Mittal [mailto:samittal@hss.hns.com]

          >      =
> > Sent: Tuesday, January 25, 2000 9:01 AM

          >      =
> > To: MEGACO@standards.nortelnetworks.com

          >      =
> > Subject: Choosing of ephemeral / physical Termination.

          >      =
> >

          >      =
> >

          >      =
> > Annex B.1 says that "The CHOOSE TerminationID $ may be =
used

          >      =
> > to signal to the MG

          >      =
> > that it has to create an

          >      =
> > ephemeral Termination or select an idle physical

          >      =
Termination".

          >      =
> > How can MG determine when to create an ephemeral =
termination

          >      =
> > and when to choose

          >      =
> > idle physical termination.??

          >      =
> > What is the logic behind this decision making?

          >      =
> >

          >      =
> > regards

          >      =
> > -Sachin Mittal

          >      =
> >

          >      =
>

          

        


------_=_NextPart_001_01BF6C04.15D55156--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 11:42:38 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09141
	for ; Mon, 31 Jan 2000 11:42:38 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E52E5080@standards.nortelnetworks.com>; Mon, 31 Jan 2000 11:39:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16023 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 11:37:58 -0500
Received: from outbound.ctcnet.com (192.187.244.145) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.39468D60@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          11:27:57 -0500
Received: from WalthamNotes3.ctcnet.com (walthamnotes3.ctcnet.com
          [192.168.60.28]) by outbound.ctcnet.com (8.8.7/8.8.7) with SMTP id
          LAA14974 for ; Mon, 31 Jan 2000
          11:30:02 -0500
Received: by WalthamNotes3.ctcnet.com(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))
          id 85256877.005AAA8C ; Mon, 31 Jan 2000 11:30:19 -0500
X-Lotus-FromDomain: CTCNET
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=DYcETaopfedQ1SgiPm8wLvIeARY206pMPmLs9fKxTDCoTcliwfx76QIo"
Content-Disposition: inline
Message-ID:  <85256877.005AAA3A.00@WalthamNotes3.ctcnet.com>
Date:         Mon, 31 Jan 2000 11:29:42 -0500
Reply-To: abruneau@CTCNET.COM
Sender: "Media Gateway Control (megaco)"
              
From: Aaron Bruneau 
Subject:      unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=DYcETaopfedQ1SgiPm8wLvIeARY206pMPmLs9fKxTDCoTcliwfx76QIo
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



unsubscribe




Stephen Terrill 
11/17/99 07:56 AM

Please respond to Stephen Terrill 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Aaron Bruneau/ctcnet)
Subject:  Re: Washington Issue 21 - Property or Signal




Hi Peter,

Can you clarify what you mean for dynamic in nature and effecting information
flow.  If this was to mean anything that was not configuration, would this imply
that RTP port and remote IP address should be sent in signals as in my view they
are not configuration, and the do effect the information flow.

Thanks,

..//Steve

Peter Blatherwick wrote:

>
>
> Yes, we need some words of guidance in the Megaco Protocol
> document on intent of Signals vs Properties and when to
> define which type in a Package.
>
>      Problem
>      Several suggested packages used a signal as a sort of arbitrary
>      function call in a package.  It seemed to the authors that
>      signals had the requisite syntax - procedure name, named and
>      typed parameters.  Signals can be "instantaneous", so, why not?
>
>      The alternative is to use properties.  Typically, several
>      properties, representing the parameters, with some explicit
>      or implied invocation of a procedure.
>      ...
>
> I would like to think of Signals as being dynamic in nature,
> and moving information or affecting information flows from
> the IP world to the outside world.
>
> Properties should be thought of as more static in nature,
> and related to configuration.  Also, since Properties are
> currently defined as values, it is quite awkward to use
> them where method call-like semantics are required,
> as is the case in many packages.
>
> More detailed reasoning and examples are below, from
> a previous e-mail on this topic..  Please read.
>
> Actually, speaking for myself anyway, the intent in the
> package definitions was not to make "arbitrary function
> calls".  Rather, we tried to define based on purpose of
> the particular interface, as above.  (Remember, the
> Signals and Properties stuff was still firming up at the time
> the original package definitions were put together, so
> there may be a few things which do not currently line up
> with this intent.  This will be fixed.)
>
> BTW, there seem to be two Issue 21s.  I suspect one is
> enough ;-)
>
> -- Peter Blatherwick
>
>
> -----Original Message-----
> From:   Blatherwick, Peter [blather@nortelnetworks.com]
> Sent:   26 Oct, 1999 12:44
> To:     Taylor, Tom-PT [taylor@nortelnetworks.com];
megaco@standards.nortelnetworks.com
> Subject:        Properties and Signals (RE: Megaco Events and Signals)
>
> Tom wrote:
> > ... I invite proposals on the distinction between signals and properties.
>
> Here are the distinctions I would draw.
>
> Signals are anything which can affect externally visible state of terminations
or the streams they carry in a dynamic way.  Since Signals currently support
parameters, this means some resolution can be achieved beyond pre-configured
default behaviour (e.g. playtone(id=x) vs playtone(id=x, timeout=y)), and
individual Signals can be reused across multiple actions (e.g. playtone(id=x),
vs playtoneX, playtoneY, ...).  Examples include:
>
> - playing of tones, announcements, etc
> - affecting line/truck state (e.g. on/off hook, etc)
> - manipulating user interface (e.g. turning indicators on and off,
>   writing to display, etc)
> (I know some will not agree with the latter example.  My reasoning is that
there is no underlying difference between sending audio streams to the end user
and sending any other sensory information.  Display, for example, definitely
sends sensory information to the user, and can be usefully looked at as
consuming streams of characters, for example in text conversation.  Also, user
interface needs the flexibility that parameters provide.)
>
> Properties are anything that affects configuration of terminations or the MG
as a whole, and are relatively static.  They may have externally visible effects
only indirectly through behaviour of Signals.  Since Properties are currently
single values (i.e. not parameterised "methods" like Signals), Properties must
be modelled by single values.  Examples include:
>
> - define/modify tone definitions
> - set timeouts and other package-specific defaults
> - set internal behaviour such as dtmf keypad echo
>
> Comments?
>
> -- Peter Blatherwick
>




--0__=DYcETaopfedQ1SgiPm8wLvIeARY206pMPmLs9fKxTDCoTcliwfx76QIo
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PEhUTUw+DQpIaSBQZXRlciwNCg0KPFA+Q2FuIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gZm9y
IGR5bmFtaWMgaW4gbmF0dXJlIGFuZCBlZmZlY3RpbmcgaW5mb3JtYXRpb24NCmZsb3cuJm5ic3A7
IElmIHRoaXMgd2FzIHRvIG1lYW4gYW55dGhpbmcgdGhhdCB3YXMgbm90IGNvbmZpZ3VyYXRpb24s
IHdvdWxkDQp0aGlzIGltcGx5IHRoYXQgUlRQIHBvcnQgYW5kIHJlbW90ZSBJUCBhZGRyZXNzIHNo
b3VsZCBiZSBzZW50IGluIHNpZ25hbHMNCmFzIGluIG15IHZpZXcgdGhleSBhcmUgbm90IGNvbmZp
Z3VyYXRpb24sIGFuZCB0aGUgZG8gZWZmZWN0IHRoZSBpbmZvcm1hdGlvbg0KZmxvdy4NCg0KPFA+
VGhhbmtzLA0KDQo8UD4uLi8vU3RldmUNCg0KPFA+UGV0ZXIgQmxhdGhlcndpY2sgd3JvdGU6DQo8
QkxPQ0tRVU9URSBUWVBFPUNJVEU+Jm5ic3A7DQoNCjxQPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9O
VCBTSVpFPS0xPlllcywgd2UgbmVlZCBzb21lIHdvcmRzIG9mIGd1aWRhbmNlDQppbiB0aGUgTWVn
YWNvIFByb3RvY29sPC9GT05UPjwvRk9OVD4NCjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQg
U0laRT0tMT5kb2N1bWVudCBvbiBpbnRlbnQgb2YgU2lnbmFscyB2cyBQcm9wZXJ0aWVzDQphbmQg
d2hlbiB0bzwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9
LTE+ZGVmaW5lIHdoaWNoIHR5cGUgaW4gYSBQYWNrYWdlLjwvRk9OVD48L0ZPTlQ+DQo8VUw+PEZP
TlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+UHJvYmxlbTwvRk9OVD48L0ZPTlQ+DQo8QlI+
PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+U2V2ZXJhbCBzdWdnZXN0ZWQgcGFja2Fn
ZXMgdXNlZCBhDQpzaWduYWwgYXMgYSBzb3J0IG9mIGFyYml0cmFyeTwvRk9OVD48L0ZPTlQ+DQo8
QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+ZnVuY3Rpb24gY2FsbCBpbiBhIHBh
Y2thZ2UuJm5ic3A7DQpJdCBzZWVtZWQgdG8gdGhlIGF1dGhvcnMgdGhhdDwvRk9OVD48L0ZPTlQ+
DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+c2lnbmFscyBoYWQgdGhlIHJl
cXVpc2l0ZSBzeW50YXggLQ0KcHJvY2VkdXJlIG5hbWUsIG5hbWVkIGFuZDwvRk9OVD48L0ZPTlQ+
DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+dHlwZWQgcGFyYW1ldGVycy4m
bmJzcDsgU2lnbmFscyBjYW4NCmJlICJpbnN0YW50YW5lb3VzIiwgc28sIHdoeSBub3Q/PC9GT05U
PjwvRk9OVD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTE+VGhlIGFsdGVy
bmF0aXZlIGlzIHRvIHVzZSBwcm9wZXJ0aWVzLiZuYnNwOw0KVHlwaWNhbGx5LCBzZXZlcmFsPC9G
T05UPjwvRk9OVD4NCjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQgU0laRT0tMT5wcm9wZXJ0
aWVzLCByZXByZXNlbnRpbmcgdGhlIHBhcmFtZXRlcnMsDQp3aXRoIHNvbWUgZXhwbGljaXQ8L0ZP
TlQ+PC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBTSVpFPS0xPm9yIGltcGxp
ZWQgaW52b2NhdGlvbiBvZiBhIHByb2NlZHVyZS48L0ZPTlQ+PC9GT05UPg0KPEJSPjxGT05UIEZB
Q0U9IkFyaWFsIj48Rk9OVCBTSVpFPS0xPi4uLjwvRk9OVD48L0ZPTlQ+PC9VTD4NCjxGT05UIEZB
Q0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT5JIHdvdWxkIGxp
a2UgdG8NCnRoaW5rIG9mIFNpZ25hbHMgYXMgYmVpbmcgZHluYW1pYyBpbiBuYXR1cmUsPC9GT05U
PjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAw
MDAwIj48Rk9OVCBTSVpFPS0xPmFuZCBtb3ZpbmcgaW5mb3JtYXRpb24NCm9yIGFmZmVjdGluZyBp
bmZvcm1hdGlvbiBmbG93cyBmcm9tPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFD
RT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPnRoZSBJUCB3b3Js
ZA0KdG8gdGhlIG91dHNpZGUgd29ybGQuPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQoNCjxQPjxGT05U
IEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT5Qcm9wZXJ0
aWVzIHNob3VsZA0KYmUgdGhvdWdodCBvZiBhcyBtb3JlIHN0YXRpYyBpbiBuYXR1cmUsPC9GT05U
PjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAw
MDAwIj48Rk9OVCBTSVpFPS0xPmFuZCByZWxhdGVkDQp0byBjb25maWd1cmF0aW9uLiZuYnNwOyBB
bHNvLCBzaW5jZSBQcm9wZXJ0aWVzIGFyZTwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KPEJSPjxGT05U
IEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT5jdXJyZW50
bHkgZGVmaW5lZA0KYXMgdmFsdWVzLCBpdCBpcyBxdWl0ZSBhd2t3YXJkIHRvIHVzZTwvRk9OVD48
L0ZPTlQ+PC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAw
MCI+PEZPTlQgU0laRT0tMT50aGVtIHdoZXJlIG1ldGhvZA0KY2FsbC1saWtlIHNlbWFudGljcyBh
cmUgcmVxdWlyZWQsPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwi
PjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPmFzIGlzIHRoZSBjYXNlDQppbiBt
YW55IHBhY2thZ2VzLjwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KDQo8UD48Rk9OVCBGQUNFPSJBcmlh
bCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+TW9yZSBkZXRhaWxlZA0KcmVh
c29uaW5nIGFuZCBleGFtcGxlcyBhcmUgYmVsb3csIGZyb208L0ZPTlQ+PC9GT05UPjwvRk9OVD4N
CjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9
LTE+YSBwcmV2aW91cyBlLW1haWwNCm9uIHRoaXMgdG9waWMuLiZuYnNwOyBQbGVhc2UgcmVhZC48
L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9S
PSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPkFjdHVhbGx5LCBzcGVha2luZw0KZm9yIG15c2VsZiBh
bnl3YXksIHRoZSBpbnRlbnQgaW4gdGhlPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQg
RkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPnBhY2thZ2Ug
ZGVmaW5pdGlvbnMNCndhcyBub3QgdG8gbWFrZSAiYXJiaXRyYXJ5IGZ1bmN0aW9uPC9GT05UPjwv
Rk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAw
Ij48Rk9OVCBTSVpFPS0xPmNhbGxzIi4mbmJzcDsNClJhdGhlciwgd2UgdHJpZWQgdG8gZGVmaW5l
IGJhc2VkIG9uIHB1cnBvc2Ugb2Y8L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCjxCUj48Rk9OVCBGQUNF
PSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+dGhlIHBhcnRpY3Vs
YXINCmludGVyZmFjZSwgYXMgYWJvdmUuJm5ic3A7IChSZW1lbWJlciwgdGhlPC9GT05UPjwvRk9O
VD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48
Rk9OVCBTSVpFPS0xPlNpZ25hbHMgYW5kDQpQcm9wZXJ0aWVzIHN0dWZmIHdhcyBzdGlsbCBmaXJt
aW5nIHVwIGF0IHRoZSB0aW1lPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0i
QXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPnRoZSBvcmlnaW5hbA0K
cGFja2FnZSBkZWZpbml0aW9ucyB3ZXJlIHB1dCB0b2dldGhlciwgc288L0ZPTlQ+PC9GT05UPjwv
Rk9OVD4NCjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05U
IFNJWkU9LTE+dGhlcmUgbWF5IGJlDQphIGZldyB0aGluZ3Mgd2hpY2ggZG8gbm90IGN1cnJlbnRs
eSBsaW5lIHVwPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxG
T05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPndpdGggdGhpcyBpbnRlbnQuJm5ic3A7
DQpUaGlzIHdpbGwgYmUgZml4ZWQuKTwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KDQo8UD48Rk9OVCBG
QUNFPSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+QlRXLCB0aGVy
ZSBzZWVtDQp0byBiZSB0d28gSXNzdWUgMjFzLiZuYnNwOyBJIHN1c3BlY3Qgb25lIGlzPC9GT05U
PjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAw
MDAwIj48Rk9OVCBTSVpFPS0xPmVub3VnaCA7LSk8L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCg0KPFA+
PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPi0t
IFBldGVyIEJsYXRoZXJ3aWNrPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQo8QlI+Jm5ic3A7DQoNCjxQ
PjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBTSVpFPS0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tPC9GT05UPjwvRk9OVD4NCjxCUj48Qj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQgU0laRT0t
Mj5Gcm9tOiZuYnNwOyZuYnNwOzwvRk9OVD48L0ZPTlQ+PC9CPg0KPEZPTlQgRkFDRT0iQXJpYWwi
PjxGT05UIFNJWkU9LTI+QmxhdGhlcndpY2ssIFBldGVyIFtibGF0aGVyQG5vcnRlbG5ldHdvcmtz
LmNvbV08L0ZPTlQ+PC9GT05UPg0KPEJSPjxCPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBTSVpF
PS0yPlNlbnQ6Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRk9OVD48L0I+DQo8Rk9OVCBGQUNFPSJBcmlh
bCI+PEZPTlQgU0laRT0tMj4yNiBPY3QsIDE5OTkgMTI6NDQ8L0ZPTlQ+PC9GT05UPg0KPEJSPjxC
PjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBTSVpFPS0yPlRvOiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOzwvRk9OVD48L0ZPTlQ+PC9CPg0KPEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJWkU9LTI+
VGF5bG9yLCBUb20tUFQgW3RheWxvckBub3J0ZWxuZXR3b3Jrcy5jb21dOw0KbWVnYWNvQHN0YW5k
YXJkcy5ub3J0ZWxuZXR3b3Jrcy5jb208L0ZPTlQ+PC9GT05UPg0KPEJSPjxCPjxGT05UIEZBQ0U9
IkFyaWFsIj48Rk9OVCBTSVpFPS0yPlN1YmplY3Q6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7PC9GT05UPjwvRk9OVD48L0I+DQo8Rk9OVCBGQUNFPSJBcmlhbCI+PEZP
TlQgU0laRT0tMj5Qcm9wZXJ0aWVzIGFuZCBTaWduYWxzIChSRTogTWVnYWNvIEV2ZW50cw0KYW5k
IFNpZ25hbHMpPC9GT05UPjwvRk9OVD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIFNJ
WkU9LTE+VG9tIHdyb3RlOjwvRk9OVD48L0ZPTlQ+DQo8QlI+PEZPTlQgRkFDRT0iQXJpYWwiPjxG
T05UIFNJWkU9LTE+PiAuLi4gSSBpbnZpdGUgcHJvcG9zYWxzIG9uIHRoZSBkaXN0aW5jdGlvbg0K
YmV0d2VlbiBzaWduYWxzIGFuZCBwcm9wZXJ0aWVzLjwvRk9OVD48L0ZPTlQ+DQoNCjxQPjxGT05U
IEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT5IZXJlIGFy
ZSB0aGUNCmRpc3RpbmN0aW9ucyBJIHdvdWxkIGRyYXcuPC9GT05UPjwvRk9OVD48L0ZPTlQ+DQoN
CjxQPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0t
MT5TaWduYWxzIGFyZSBhbnl0aGluZw0Kd2hpY2ggY2FuIGFmZmVjdCBleHRlcm5hbGx5IHZpc2li
bGUgc3RhdGUgb2YgdGVybWluYXRpb25zIG9yIHRoZSBzdHJlYW1zDQp0aGV5IGNhcnJ5IGluIGEg
ZHluYW1pYyB3YXkuJm5ic3A7IFNpbmNlIFNpZ25hbHMgY3VycmVudGx5IHN1cHBvcnQgcGFyYW1l
dGVycywNCnRoaXMgbWVhbnMgc29tZSByZXNvbHV0aW9uIGNhbiBiZSBhY2hpZXZlZCBiZXlvbmQg
cHJlLWNvbmZpZ3VyZWQgZGVmYXVsdA0KYmVoYXZpb3VyIChlLmcuIHBsYXl0b25lKGlkPXgpIHZz
IHBsYXl0b25lKGlkPXgsIHRpbWVvdXQ9eSkpLCBhbmQgaW5kaXZpZHVhbA0KU2lnbmFscyBjYW4g
YmUgcmV1c2VkIGFjcm9zcyBtdWx0aXBsZSBhY3Rpb25zIChlLmcuIHBsYXl0b25lKGlkPXgpLCB2
cw0KcGxheXRvbmVYLCBwbGF5dG9uZVksIC4uLikuJm5ic3A7IEV4YW1wbGVzIGluY2x1ZGU6PC9G
T05UPjwvRk9OVD48L0ZPTlQ+DQoNCjxQPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0i
IzAwMDAwMCI+PEZPTlQgU0laRT0tMT4tIHBsYXlpbmcgb2YNCnRvbmVzLCBhbm5vdW5jZW1lbnRz
LCBldGM8L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQg
Q09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+LSBhZmZlY3RpbmcNCmxpbmUvdHJ1Y2sgc3Rh
dGUgKGUuZy4gb24vb2ZmIGhvb2ssIGV0Yyk8L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCjxCUj48Rk9O
VCBGQUNFPSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+LSBtYW5p
cHVsYXRpbmcNCnVzZXIgaW50ZXJmYWNlIChlLmcuIHR1cm5pbmcgaW5kaWNhdG9ycyBvbiBhbmQg
b2ZmLDwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBD
T0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT4mbmJzcDsgd3JpdGluZw0KdG8gZGlzcGxheSwg
ZXRjKTwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBD
T0xPUj0iIzAwMDAwMCI+PEZPTlQgU0laRT0tMT4oSSBrbm93IHNvbWUNCndpbGwgbm90IGFncmVl
IHdpdGggdGhlIGxhdHRlciBleGFtcGxlLiZuYnNwOyBNeSByZWFzb25pbmcgaXMgdGhhdCB0aGVy
ZQ0KaXMgbm8gdW5kZXJseWluZyBkaWZmZXJlbmNlIGJldHdlZW4gc2VuZGluZyBhdWRpbyBzdHJl
YW1zIHRvIHRoZSBlbmQgdXNlcg0KYW5kIHNlbmRpbmcgYW55IG90aGVyIHNlbnNvcnkgaW5mb3Jt
YXRpb24uJm5ic3A7IERpc3BsYXksIGZvciBleGFtcGxlLA0KZGVmaW5pdGVseSBzZW5kcyBzZW5z
b3J5IGluZm9ybWF0aW9uIHRvIHRoZSB1c2VyLCBhbmQgY2FuIGJlIHVzZWZ1bGx5IGxvb2tlZA0K
YXQgYXMgY29uc3VtaW5nIHN0cmVhbXMgb2YgY2hhcmFjdGVycywgZm9yIGV4YW1wbGUgaW4gdGV4
dCBjb252ZXJzYXRpb24uJm5ic3A7DQpBbHNvLCB1c2VyIGludGVyZmFjZSBuZWVkcyB0aGUgZmxl
eGliaWxpdHkgdGhhdCBwYXJhbWV0ZXJzIHByb3ZpZGUuKTwvRk9OVD48L0ZPTlQ+PC9GT05UPg0K
DQo8UD48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9
LTE+UHJvcGVydGllcyBhcmUNCmFueXRoaW5nIHRoYXQgYWZmZWN0cyBjb25maWd1cmF0aW9uIG9m
IHRlcm1pbmF0aW9ucyBvciB0aGUgTUcgYXMgYSB3aG9sZSwNCmFuZCBhcmUgcmVsYXRpdmVseSBz
dGF0aWMuJm5ic3A7IFRoZXkgbWF5IGhhdmUgZXh0ZXJuYWxseSB2aXNpYmxlIGVmZmVjdHMNCm9u
bHkgaW5kaXJlY3RseSB0aHJvdWdoIGJlaGF2aW91ciBvZiBTaWduYWxzLiZuYnNwOyBTaW5jZSBQ
cm9wZXJ0aWVzIGFyZQ0KY3VycmVudGx5IHNpbmdsZSB2YWx1ZXMgKGkuZS4gbm90IHBhcmFtZXRl
cmlzZWQgIm1ldGhvZHMiIGxpa2UgU2lnbmFscyksDQpQcm9wZXJ0aWVzIG11c3QgYmUgbW9kZWxs
ZWQgYnkgc2luZ2xlIHZhbHVlcy4mbmJzcDsgRXhhbXBsZXMgaW5jbHVkZTo8L0ZPTlQ+PC9GT05U
PjwvRk9OVD4NCg0KPFA+PEZPTlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48
Rk9OVCBTSVpFPS0xPi0gZGVmaW5lL21vZGlmeQ0KdG9uZSBkZWZpbml0aW9uczwvRk9OVD48L0ZP
TlQ+PC9GT05UPg0KPEJSPjxGT05UIEZBQ0U9IkFyaWFsIj48Rk9OVCBDT0xPUj0iIzAwMDAwMCI+
PEZPTlQgU0laRT0tMT4tIHNldCB0aW1lb3V0cw0KYW5kIG90aGVyIHBhY2thZ2Utc3BlY2lmaWMg
ZGVmYXVsdHM8L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCjxCUj48Rk9OVCBGQUNFPSJBcmlhbCI+PEZP
TlQgQ09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+LSBzZXQgaW50ZXJuYWwNCmJlaGF2aW91
ciBzdWNoIGFzIGR0bWYga2V5cGFkIGVjaG88L0ZPTlQ+PC9GT05UPjwvRk9OVD4NCg0KPFA+PEZP
TlQgRkFDRT0iQXJpYWwiPjxGT05UIENPTE9SPSIjMDAwMDAwIj48Rk9OVCBTSVpFPS0xPkNvbW1l
bnRzPzwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KDQo8UD48Rk9OVCBGQUNFPSJBcmlhbCI+PEZPTlQg
Q09MT1I9IiMwMDAwMDAiPjxGT05UIFNJWkU9LTE+LS0gUGV0ZXIgQmxhdGhlcndpY2s8L0ZPTlQ+
PC9GT05UPjwvRk9OVD4NCjxCUj4mbmJzcDs8L0JMT0NLUVVPVEU+DQombmJzcDs8L0hUTUw+DQoN
Cg==

--0__=DYcETaopfedQ1SgiPm8wLvIeARY206pMPmLs9fKxTDCoTcliwfx76QIo--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 12:50:56 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10945
	for ; Mon, 31 Jan 2000 12:50:55 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CD873E0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 12:48:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16171 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 12:46:25 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.2F2EC710@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          12:46:25 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 11:48:17 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 12:48:05 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LMDNB>; Mon, 31 Jan 2000 12:48:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C13.52613E0A"
Message-ID:  
Date:         Mon, 31 Jan 2000 12:47:56 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Importance of ContextID in ServiceChange command
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C13.52613E0A
Content-Type: text/plain

I've thought about this a bit more, and I think it's wrong.  Where
ServiceChange applies to an individual termination rather than ROOT, the
sender should provide the contextID of the context in which the termination
currently exists.  This makes it easier for the other end to process the
command.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Monday, January 31, 2000 2:54 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Re: Importance of ContextID in ServiceChange command
>
>
>
> Need to add this in text. Somehow missed in V14.
>
>
>
>
> Tom-PT Taylor  on 01/28/2000 02:28:57 AM
>
> Please respond to Tom-PT Taylor 
>
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin Mittal/HSS)
>
> Subject:  Re: Importance of ContextID in ServiceChange command
>
>
>
>
> Good point.
>
> > -----Original Message-----
> > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> > Sent: Thursday, January 27, 2000 4:07 AM
> > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject:      Importance of ContextID in ServiceChange command
> >
> > HI all
> >
> > It should be mentioned somewhere in the text that there is no
> > siginificance of
> > ContextID in case of ServiceChange Command. The ServiceChange command
> > is for terminations and no validation is done on ContextID should be
> done.
>  << File: Internet HTML >>

------_=_NextPart_001_01BF6C13.52613E0A
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Importance of ContextID in ServiceChange command




        I've thought about =
this a bit more, and I think it's wrong.  Where ServiceChange =
applies to an individual termination rather than ROOT, the sender =
should provide the contextID of the context in which the termination =
currently exists.  This makes it easier for the other end to =
process the command.
        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Monday, January 31, 2000 2:54 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Re: Importance of ContextID in =
ServiceChange command

          

          

          


          Need to add this in text. Somehow =
missed in V14.

          

          

          

          


          Tom-PT Taylor =
<taylor@NORTELNETWORKS.COM> on 01/28/2000 02:28:57 AM

          


          Please respond to Tom-PT Taylor =
<taylor@NORTELNETWORKS.COM>

          


          To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          cc:    (bcc: Sachin =
Mittal/HSS)

          


          Subject:  Re: Importance of =
ContextID in ServiceChange command

          

          

          

          


          Good point.

          


          > -----Original Message-----

          > From: Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          > Sent: Thursday, January 27, 2000 =
4:07 AM

          > To:   =
MEGACO@STANDARDS.NORTELNETWORKS.COM

          > =
Subject:      Importance of ContextID in =
ServiceChange command

          >

          > HI all

          >

          > It should be mentioned somewhere =
in the text that there is no

          > siginificance of

          > ContextID in case of =
ServiceChange Command. The ServiceChange command

          > is for terminations and no =
validation is done on ContextID should be done.

           << File: Internet HTML =
>> 

          

        


------_=_NextPart_001_01BF6C13.52613E0A--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 12:53:46 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11017
	for ; Mon, 31 Jan 2000 12:53:46 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B4A69030@standards.nortelnetworks.com>; Mon, 31 Jan 2000 12:50:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16156 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 12:48:23 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.0FF67CE0@standards.nortelnetworks.com>;
          Mon, 31 Jan 2000 12:38:23 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id LAA22405
          for ; Mon, 31 Jan 2000 11:40:00
          -0600 (CST)
Received: from relay2.dsccc.com(143.209.238.7) by fw7 via smap (V2.0) id
          xma022254; Mon, 31 Jan 00 11:39:50 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id LAA06807 for
          ; Mon, 31 Jan 2000 11:40:53
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAC4FBD for
          ; Mon, 31 Jan 2000 11:39:48 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id LAA08595 for ; Mon, 31
          Jan 2000 11:39:08 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA16226
          for ; Mon, 31 Jan 2000 11:39:08
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------14DC1CF16E1434415D6774CC"
Message-ID:  <3895C8BB.168D7CEC@usa.alcatel.com>
Date:         Mon, 31 Jan 2000 11:39:08 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      ServiceChangeAddress
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------14DC1CF16E1434415D6774CC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

v14 section 7.2.8 ServiceChange

"Summarizing use of properties in the ServiceChange Descriptor:"
" . ServiceChangeAddress mandatory when the terminationID is ROOT ..."

This contradicts statements in Section 7.2.8:
"The MG may specify the transport ServiceChangeAddress ...."
"The MGC may specify the ServiceChangeAddress for the MG to use ..."

 and Section D.2 using TCP:
"When no port is specified by the other side (see section 7.2.8), the
commands should be
sent to the default port."

(Also it looks like ServiceChangeAddress could be an example of
"Unspecified mandatory parameter".
if there were such a thing to start with)


Chuong

--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------14DC1CF16E1434415D6774CC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hi

        v14 section 7.2.8 ServiceChange

        "Summarizing use of properties in the ServiceChange Descriptor:"

        " . ServiceChangeAddress mandatory when the terminationID is ROOT ..."

        This contradicts statements in Section 7.2.8:

        "The MG may specify the transport ServiceChangeAddress ...."

        "The MGC may specify the ServiceChangeAddress for the MG to use
..."

         and Section D.2 using TCP:

        "When no port is specified by the other side (see section 7.2.8), the
commands should be

        sent to the default port."

        (Also it looks like ServiceChangeAddress could be an example of "Unspecified
mandatory parameter".

        if there were such a thing to start with)

         

        Chuong

        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------14DC1CF16E1434415D6774CC--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 13:58:59 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12788
	for ; Mon, 31 Jan 2000 13:58:59 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F2B8D3C0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 13:56:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16279 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 13:55:06 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.C767F5C0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          13:55:06 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 12:55:56 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 13:55:46
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1BKLFM8G>; Mon, 31 Jan 2000 12:55:44 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C1C.C711B9D8"
Message-ID:  
Date:         Mon, 31 Jan 2000 12:55:38 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: v14: Change required in Audit command description
X-To:         samittal@HSS.HNS.COM
X-cc:         "John Segers (E-mail)" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C1C.C711B9D8
Content-Type: text/plain

OK, folks, what is the intent?  The obvious route is to make auditDescriptor
mandatory in the AuditRequest production in both Annex A and Annex B.

> -----Original Message-----
> From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
> Sent: Monday, January 31, 2000 2:40 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      v14: Change required in Audit command description
>
> In Section 7.2.5 & 6. the Audit descriptor is not shown to be optional but
> auditRequest in grammar shows it to be optional.
> This should be changed one way or the other.

------_=_NextPart_001_01BF6C1C.C711B9D8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: v14: Change required in Audit command description




        OK, folks, what is =
the intent?  The obvious route is to make auditDescriptor =
mandatory in the AuditRequest production in both Annex A and Annex =
B.
        

          

          -----Original Message-----

          From:   Sachin Mittal =
[SMTP:samittal@HSS.HNS.COM]

          Sent:   Monday, January 31, 2000 2:40 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 v14: Change required in Audit =
command description

          


          In Section 7.2.5 & 6. the Audit =
descriptor is not shown to be optional but

          auditRequest in grammar shows it to =
be optional.

          This should be changed one way or the =
other.

          

        


------_=_NextPart_001_01BF6C1C.C711B9D8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 14:12:06 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13226
	for ; Mon, 31 Jan 2000 14:12:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C47C5CA0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 14:09:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16288 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 14:07:38 -0500
Received: from fw7.dsccc.com by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1a) with SMTP id <0.21DB2C20@standards.nortelnetworks.com>;
          Mon, 31 Jan 2000 13:57:37 -0500
Received: (from uucp@localhost) by fw7.dsccc.com (8.8.8+Sun/8.8.8) id MAA02313
          for ; Mon, 31 Jan 2000 12:59:32
          -0600 (CST)
Received: from relay1.dsccc.com(143.209.238.6) by fw7 via smap (V2.0) id
          xma002261; Mon, 31 Jan 00 12:58:53 -0600
Received: from psun6.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.8.8) with ESMTP id MAA04614 for
          ; Mon, 31 Jan 2000 12:58:51
          -0600 (CST)
Received: from ssd.usa.alcatel.com ([127.0.0.1]) by psun6.usa.alcatel.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAA515A for
          ; Mon, 31 Jan 2000 12:58:50 -0600
Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com
          [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with
          ESMTP id MAA22659 for ; Mon, 31
          Jan 2000 12:58:46 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id MAA16330
          for ; Mon, 31 Jan 2000 12:58:45
          -0600 (CST)
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/alternative;
              boundary="------------F5C9FABE0BFC53ACE2E461B1"
Message-ID:  <3895DB65.11CE405F@usa.alcatel.com>
Date:         Mon, 31 Jan 2000 12:58:45 -0600
Reply-To: Chuong Nguyen 
Sender: "Media Gateway Control (megaco)"
              
From: Chuong Nguyen 
Subject:      Re: Importance of ContextID in ServiceChange command
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--------------F5C9FABE0BFC53ACE2E461B1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It will depends on the scenario.  Therefore it is an implementation
issue.  Thus it should not
be a requirement to provide contextId.
For example, what if someone wants to take a range of terminations out
of service via wildcards.
The contextId would be different for that range of terminations.

For an individual termination, it should be allowed but not mandatory.
But simplicity is better here.

Chuong

Tom-PT Taylor wrote:

>
>
> I've thought about this a bit more, and I think it's wrong.  Where
> ServiceChange applies to an individual termination rather than ROOT,
> the sender should provide the contextID of the context in which the
> termination currently exists.  This makes it easier for the other end
> to process the command.
>
>      -----Original Message-----
>      From:  Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>      Sent:  Monday, January 31, 2000 2:54 AM
>      To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
>      Subject:       Re: Importance of ContextID in ServiceChange
>      command
>
>
>      Need to add this in text. Somehow missed in V14.
>
>
>
>      Tom-PT Taylor  on 01/28/2000 02:28:57
>      AM
>
>      Please respond to Tom-PT Taylor 
>
>      To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>      cc:    (bcc: Sachin Mittal/HSS)
>
>      Subject:  Re: Importance of ContextID in ServiceChange command
>
>
>
>      Good point.
>
>      > -----Original Message-----
>      > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]
>      > Sent: Thursday, January 27, 2000 4:07 AM
>      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
>      > Subject:      Importance of ContextID in ServiceChange command
>      >
>      > HI all
>      >
>      > It should be mentioned somewhere in the text that there is no
>      > siginificance of
>      > ContextID in case of ServiceChange Command. The ServiceChange
>      command
>      > is for terminations and no validation is done on ContextID
>      should be done.
>       << File: Internet HTML >>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



--------------F5C9FABE0BFC53ACE2E461B1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit



It will depends on the scenario.  Therefore it is an implementation
issue.  Thus it should not

        be a requirement to provide contextId.

        For example, what if someone wants to take a range of terminations
out of service via wildcards.

        The contextId would be different for that range of terminations.

        For an individual termination, it should be allowed but not mandatory.

        But simplicity is better here.

        Chuong

        Tom-PT Taylor wrote:

         

        I've thought
about this a bit more, and I think it's wrong.  Where ServiceChange
applies to an individual termination rather than ROOT, the sender should
provide the contextID of the context in which the termination currently
exists.  This makes it easier for the other end to process the command.

          -----Original Message-----

          From:  Sachin Mittal [SMTP:samittal@HSS.HNS.COM]

          Sent:  Monday, January
31, 2000 2:54 AM

          To:    MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:      
Re: Importance of ContextID in ServiceChange command

           

          Need to add this in text. Somehow missed
in V14.

           

           

          Tom-PT Taylor <taylor@NORTELNETWORKS.COM>
on 01/28/2000 02:28:57 AM

          Please respond to Tom-PT Taylor <taylor@NORTELNETWORKS.COM>

          To:   MEGACO@STANDARDS.NORTELNETWORKS.COM

          cc:    (bcc: Sachin
Mittal/HSS)

          Subject:  Re: Importance of ContextID
in ServiceChange command

           

           

          Good point.

          > -----Original Message-----

          > From: Sachin Mittal [SMTP:samittal@HSS.HNS.COM]

          > Sent: Thursday, January 27, 2000
4:07 AM

          > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM

          > Subject:     
Importance of ContextID in ServiceChange command

          >

          > HI all

          >

          > It should be mentioned somewhere
in the text that there is no

          > siginificance of

          > ContextID in case of ServiceChange
Command. The ServiceChange command

          > is for terminations and no validation
is done on ContextID should be done.

           << File: Internet HTML
>>
        

        


        -- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
        
 

--------------F5C9FABE0BFC53ACE2E461B1--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 14:32:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13892
	for ; Mon, 31 Jan 2000 14:32:02 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.91C7FC80@standards.nortelnetworks.com>; Mon, 31 Jan 2000 14:29:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16333 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 14:28:15 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.691521F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          14:28:15 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 13:30:03 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 14:29:18 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LMJA1>; Mon, 31 Jan 2000 14:29:19 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C21.77B9A940"
Message-ID:  
Date:         Mon, 31 Jan 2000 14:29:13 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: ServiceChangeAddress
X-To:         Chuong Nguyen 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C21.77B9A940
Content-Type: text/plain

I've marked this as an erratum -- change "mandatory" to "optional" and
otherwise leave the bullet as is.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Monday, January 31, 2000 12:39 PM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      ServiceChangeAddress
>
> Hi
>
> v14 section 7.2.8 ServiceChange
>
> "Summarizing use of properties in the ServiceChange Descriptor:"
> " . ServiceChangeAddress mandatory when the terminationID is ROOT ..."
>
> This contradicts statements in Section 7.2.8:
> "The MG may specify the transport ServiceChangeAddress ...."
> "The MGC may specify the ServiceChangeAddress for the MG to use ..."
>
>  and Section D.2 using TCP:
> "When no port is specified by the other side (see section 7.2.8), the
> commands should be
> sent to the default port."
>
> (Also it looks like ServiceChangeAddress could be an example of
> "Unspecified mandatory parameter".
> if there were such a thing to start with)
>
>
> Chuong
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>

------_=_NextPart_001_01BF6C21.77B9A940
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: ServiceChangeAddress




        I've marked this as =
an erratum -- change "mandatory" to "optional" and =
otherwise leave the bullet as is.

        

          

          -----Original Message-----

          From:   Chuong Nguyen =
[SMTP:Chuong.Nguyen@USA.ALCATEL.COM]

          Sent:   Monday, January 31, 2000 12:39 PM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 ServiceChangeAddress

          


          Hi 

          


          v14 section 7.2.8 ServiceChange 

          


          "Summarizing use of properties in the =
ServiceChange Descriptor:"
          
" . ServiceChangeAddress mandatory when the terminationID is ROOT =
..."           

          


          This contradicts statements in Section =
7.2.8:
          
"The MG may specify the transport ServiceChangeAddress =
...."
          
"The MGC=A0may specify the ServiceChangeAddress for the MG to use =
..."           

          


          =A0and Section D.2 using TCP:
          
"When no port is specified by the other side (see section 7.2.8), =
the commands should be
          
sent to the default port."           

          


          (Also it looks like ServiceChangeAddress could =
be an example of "Unspecified mandatory parameter".
          
if there were such a thing to start with)
          
=A0           

          


          Chuong 

          --=A0
          
=A0 Alcatel USA, Inc=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Internet: =
Chuong.Nguyen@usa.alcatel.com
          
=A0 1000 Coit Road Plano, Texas 75075=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Phone:=A0=A0=A0 (972) 519-4613
          
=A0 **** The opinions expressed are not those of Alcatel USA, Inc =
****          

          =A0

          

        


------_=_NextPart_001_01BF6C21.77B9A940--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 14:52:02 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14371
	for ; Mon, 31 Jan 2000 14:52:01 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E22D3C0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 14:49:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16349 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 14:47:51 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.C07D1EB0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 14:37:51
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id OAA28675; Mon, 31 Jan
          2000 14:39:50 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id OAA26419; Mon, 31 Jan
          2000 14:39:51 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 31 Jan 2000 14:36:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208863@whq-msgusr-02.fore.com>
Date:         Mon, 31 Jan 2000 14:39:49 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Choosing of ephemeral / physical Termination.
X-To:         Christian Groves 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Just checking my assumptions:
        For a physical termination, you want to be able to say:
                MyDS3/3/$
       meaning, you choose any DS0 you want in the 3rd DS1 of a DS3,
assuming that
         was how my MG named the DS0s (such a structure NOT being required).
Could
        I also ask for MyDS3/$/$?

        For an ephemeral termination, suppose that I knew, by discovery or
        provisioning that RTP bearers were named RTP/nnnn and ATM bearers
were
        named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which means create an
        ephemeral for an ATM AAL1 bearer, with the MG choosing the
subchannel?

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, January 31, 2000 10:27 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Choosing of ephemeral / physical Termination.
>
>
> Hello all,
>
> I believe that we have diverged from the first email in this
> thread. We
> do not need rules to determine what media and bearer is instantiated.
>
> For a physical termination a certain terminationID schema will be
> assigned by the MG. ie. /myscheme/physical/trunk/circuit
> If the MGC wanted to CHOOSE a physical termination it could either
> wildcard 'trunk' or 'circuit'.
>
> For a emphemeral terminatoion a certain terminationID schema will be
> assigned by the MG. The MGC by various means would be aware of this
> scheme.
> ie. /myscheme/euphemeral/IP
> If the MGC wanted to CHOOSE a euphemeral termination it could wilcard
> the 'IP'
>
> The 'physical' and 'ephemeral' could be anything in the the
> MG assigned
> scheme that would differentiate the two.
>
> If the MGC doesn't care which one then it CHOOSES on the
> 'ephemeral'/'physical' level. The MG can determine which one to return
> from ANY information in the media descriptors. This is
> something for the
> MG to decide, not something that needs to be specified in
> rules in H248
> because they'll probably change according to your
> application, resource
> allocation algorithms in the MG, etc. I do agree that an
> error should be
> returned if the MG cannot determine the terminationID.
>
> I think the scope of this is also limited to the ADD command. The ADD
> will return a fully specified terminationID which can then be
> referenced
> in Move, Modify, Subtract etc.
>
> Regards, Christian
>
> Tom-PT Taylor wrote:
> >
> > Right, we haven't converged yet.  I have a suggestion which may
> > resolve this, that we add these rules
> >
> > (1) If the MGC provides too little information in an Add command for
> > the MG to select the bearer type for that termination, the MG must
> > reject the command with [appropriate error].  In practice,
> this means
> > either that the terminationID in the command provides the necessary
> > information, or else that at least one instance of a Local or Remote
> > descriptor must be present, containing a c= line with a specified
> > nettype (or the Annex C equivalent).
> >
> > (2) If the MGC provides too little information in an Add, Move, or
> > Modify command for the MG to determine the medium to be carried in a
> > given stream, the MG must reject the command with [appropriate
> > error].  The MG has three ways to determine medium:
> >
> >  - streamID unspecified defaults to streamID=1 and medium=audio
> >  - medium has already been specified for that streamID for another
> > termination in the same context
> >  - explicit specification of medium in an m= line (or the Annex C
> > equivalent) in an instance of Local or Remote for the given
> streamID.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Monday, January 31, 2000 9:15 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Re: Choosing of ephemeral / physical
> Termination.
> >
> >      I believe we have not reached consensus on this issue, so I did
> >      not
> >      change the text.  Tom, is that your view?
> >
> >      Brian
> >
> >      > -----Original Message-----
> >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > Sent: Monday, January 31, 2000 2:52 AM
> >      > To: MEGACO@standards.nortelnetworks.com
> >      > Subject: Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      > The point that "$" is for choosing ephemeral is not yet added
> >      > in V14. Is it that
> >      > the discussion
> >      > is not yet complete? What about foo$ representing choose
> >      physical.
> >      >
> >      >
> >      >
> >      >
> >      > Sachin Mittal  on 01/27/2000 11:35:50 AM
> >      >
> >      > Please respond to samittal@hns.com
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Its true that the type of termination should not be
> >      > identified by looking into
> >      > the descriptor
> >      > information. Somewhere in the text this should be added that
> >      > " $ if it appears
> >      > alone indicates
> >      > ephemeral termination and partial $ (ex foo$) indicates
> >      > selection of a physical
> >      > termination
> >      > (a circuit within a trunk group)".
> >      >
> >      >
> >      >
> >      >
> >      > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
> >      >
> >      > Please respond to "Rosen, Brian" 
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Generally determined by the "kind" of termination requested.
> >      > Which is in turn, easily discernable from the Media command.
> >      >
> >      > However, upon reflection, I think it's not a good answer.
> >      > I'd propose that we not allow selection of a physical
> >      termination,
> >      > in which case choose is always create an ephemeral.  In
> >      particular,
> >      > the following is perfectly legal:
> >      > Context=${Add=${}}
> >      > What do you get?
> >      >
> >      > Brian
> >      >
> >      > > -----Original Message-----
> >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> >      > > To: MEGACO@standards.nortelnetworks.com
> >      > > Subject: Choosing of ephemeral / physical Termination.
> >      > >
> >      > >
> >      > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >      > > to signal to the MG
> >      > > that it has to create an
> >      > > ephemeral Termination or select an idle physical
> >      Termination".
> >      > > How can MG determine when to create an ephemeral
> termination
> >      > > and when to choose
> >      > > idle physical termination.??
> >      > > What is the logic behind this decision making?
> >      > >
> >      > > regards
> >      > > -Sachin Mittal
> >      > >
> >      >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 15:30:19 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15033
	for ; Mon, 31 Jan 2000 15:30:19 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF5B6C20@standards.nortelnetworks.com>; Mon, 31 Jan 2000 15:27:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16400 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 15:26:23 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.87F3D640@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          15:26:23 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 14:27:50 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 15:27:39 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LML21>; Mon, 31 Jan 2000 15:27:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C29.9D06CED2"
Message-ID:  
Date:         Mon, 31 Jan 2000 15:27:34 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Virtual MG & Root
X-To:         "Rosen, Brian" 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C29.9D06CED2
Content-Type: text/plain

We're not talking about reboot in the sense of restarting the operating
system -- the operations involved have a much narrower scope.  How strongly
do you feel on this one?

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Friday, January 28, 2000 2:28 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Virtual MG & Root
>
> The problem is Restart of Root.  This is a "warm boot".  If one Virtual MG
> does it,
> it will happen to all Virtual MGs unless you have a pretty complex
> implementation
> that can "fake" a warm boot without actually restarting the system.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Thursday, January 27, 2000 4:33 PM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Cisco SG16: Virtual MG & Root
>
>
>
>       I think this is a reasonable proposal.  When the sentence in
> question was placed there, people had visions of one MGC knocking out the
> whole (physical) MG.  If we simply interpret ServiceChange to be limited
> in scope to the virtual MG, it allows, for instance, an MGC to shed load
> by handing over responsibility for that virtual MG to another controller.
>
>               -----Original Message-----
>       From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
>       Sent:   Tuesday, January 25, 2000 8:08 PM
>       To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>       Subject:        Cisco SG16: Virtual MG & Root
>
>               Section:        11.1, second last paragraph
>       Category:       Technical/Editorial
>       Issue:          The draft text specifies that "Each virtual MG has
> its own Root
>       Termination" but "ServiceChange may only be applied to the Root by
> the
>       Master MGC". The two statements seem to be inconsistent as the
> purpose of
>       the virtual MG (and thereby the root termination for that virtual
> MG) is to
>       allow the MGC for the virtual MG to control that virtual MG.
>       Proposal:       It is proposed, that the last sentence is removed
> since each
>       virtual MG has its own Root termination.
>
>               v13 Status:     OPEN. No relevant text changed.
>
>               Support NetAid!  
>       --------------------------------------------------
>       Chip Sharp                 Consulting Engineering
>       Cisco Systems              Telco Bio-region
>       Reality - Love it or Leave it.
>       --------------------------------------------------
>

------_=_NextPart_001_01BF6C29.9D06CED2
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Virtual MG & Root




        We're not talking =
about reboot in the sense of restarting the operating system -- the =
operations involved have a much narrower scope.  How strongly do =
you feel on this one? 
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Friday, January 28, 2000 2:28 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Cisco SG16: Virtual MG & =
Root

          


          The problem is =
Restart of Root.=A0 This is a "warm boot".=A0 If one Virtual =
MG does it,

          it will happen to =
all Virtual MGs unless you have a pretty complex implementation

          that can =
"fake" a warm boot without actually restarting the =
system.

          =A0

          Brian

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Thursday, January 27, 2000 4:33 PM
            
            To: MEGACO@standards.nortelnetworks.com
            
            Subject: Re: Cisco SG16: Virtual MG & Root
            

            
            

            


            I think this is a =
reasonable proposal.=A0 When the sentence in question was placed there, =
people had visions of one MGC knocking out the whole (physical) MG.=A0 =
If we simply interpret ServiceChange to be limited in scope to the =
virtual MG, it allows, for instance, an MGC to shed load by handing =
over responsibility for that virtual MG to another =
controller.
            


                    -----Original Message-----
            
            From:=A0=A0 Chip Sharp =
[SMTP:chsharp@CISCO.COM]
            
            Sent:=A0=A0 Tuesday, January =
25, 2000 8:08 PM
            
            To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 Cisco SG16: =
Virtual MG & Root 

            


                    Section:=A0=A0=A0=A0=A0=A0=A0 11.1, second last =
paragraph
            
            Category:=A0=A0=A0=A0=A0=A0 =
Technical/Editorial
            
            Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
The draft text specifies that "Each virtual MG has its own =
Root
            
            Termination" but =
"ServiceChange may only be applied to the Root by the
            
            Master MGC". The two =
statements seem to be inconsistent as the purpose of
            
            the virtual MG (and thereby the =
root termination for that virtual MG) is to
            
            allow the MGC for the virtual MG =
to control that virtual MG.
            
            Proposal:=A0=A0=A0=A0=A0=A0 It is =
proposed, that the last sentence is removed since each
            
            virtual MG has its own Root =
termination. 

            


                    v13 Status:=A0=A0=A0=A0 OPEN. No relevant text =
changed. 

            


                    Support NetAid!=A0 <http://www.netaid.org>
            
            --------------------------------------------------=

            
            Chip =
Sharp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Consulting =
Engineering
            
            Cisco =
Systems=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Telco =
Bio-region
            
            Reality - Love it or Leave =
it.
            
            --------------------------------------------------=
 

            

        


------_=_NextPart_001_01BF6C29.9D06CED2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 15:41:09 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15282
	for ; Mon, 31 Jan 2000 15:41:09 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3982E530@standards.nortelnetworks.com>; Mon, 31 Jan 2000 15:38:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16416 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 15:37:25 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.12A7FEF0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          15:37:25 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 14:38:24 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 15:37:46
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1BKLFQVJ>; Mon, 31 Jan 2000 14:37:44 -0600
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Mon, 31 Jan 2000 14:37:41 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Issue Score Card
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The note is meant to track issues raised from 14 Jan 2000 onwards.  This
date seemed to be a reasonable starting point, since that is effectively
when work on v14 started.  Disposition of the issues is one of:
 -- "error", denoting something broken or inconsistent in current text,
which will go into an errata sheet for rectification in Geneva; or   --
"clarification needed", which will probably go into the H.248v1
Implementor's Guide (but once there, can perhaps be incorporated directly
into the Megaco RFC), or
 -- "missing functionality" which we'll have to allocate to H.248v1 or
H.248v2.

Errata
=====

Section affected: 7.1.14.

Erratum: paragraph beginning "In addition to these event symbols, the string
may contain ..."
The "S" duration modifier is unexplained and should be deleted.

Erratum: numbered paragraph 4. in description of processing behaviour,
delete specific reference to DTMF package.  Replace the final part of the
sentence beginning with "... the DTMF package ..." by the phrase "... the
package whose events are being mapped into the digit map string."

Erratum: example at end of section.  The "L" and "S" modifiers should be
deleted.  The "*" and "#" symbols should instead be "E" and "F" in
accordance with the mapping in the DTMF detection event package (see erratum
for section E.6).

Section affected: 7.2.5
Erratum: third sentence before table at end, replace "unspecified" with
"wildcarded".
References:
Raised: Madhu Babu, 14/01/00, "unspecified" Context Identifier for Audit
Command
also Selvam Rengaswami, 27/01/00, Telcordia SG16: Comments on 8.1.2
regarding ContextIDs in H.2 48
Fix per Brian Rosen, 14/01/00, "unspecified" Context Identifier for Audit
Command

Section affected: 7.2.8
Erratum: bullets summarizing use of ServiceChange parameters.  For
ServiceChangeAddress, rpelace "mandatory" by "optional", leaving rest of
bullet unchanged.
Reference: Chuong Nguyen, 31/01/00, ServiceChangeAddress

Section affected: 9.
Erratum: in second paragraph, where IP ports are specified: expect to obtain
the same value of port number for both TCP and UDP, but a different set of
ports for text vs. binary operation.
Raised: Christian Huitema, 14/01/00, FW: Application for port-number
Status: Chair has applied for second pair of port numbers for binary
operation.  Assigned port numbers should be known before decision of H.248.

Section affected: Annex A, section A.2
Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest
production.
Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command
description

Section affected: Annex A, section A.3
Erratum: in production "digitLetter", "ditigMapLetter" should be replaced by
"digitMapLetter".
Erratum: in accordance with section 7.1.14, the production "digitMapLetter"
should include the following symbols only: "0" through "9", "A" through "K",
and the long duration modifier "L".  Production MFsig should be deleted.

Section affected: Annex B, section B.2

Erratum: delete OPTIONAL for the auditDescriptor term in the AuditRequest
production.
Reference: Sachin Mittal, 31/01/00, v 14: Change required in Audit command
description

Erratum: in accordance with section 7.1.14, the production "digitMapLetter"
should include the following symbols only: "0" through "9", "A" through "K",
and the long duration modifier "L".  Production MFsig should be deleted.

Section affected: Annex E, section E.5.3
Erratum: event name d* is not a legal production, and should be changed to
ds ("s" for "star").  Similarly, event name d# should become do ("o" for
"octothorpe").

Section affected: Annex E, section E.6.2
Erratum: include the following text and table to provide mapping between
DTMF events and digit map symbols:

"The following table maps DTMF events to digit map symbols, for use as
described in section 7.1.14:"

    DTMF Event     Digit Map
                    Symbol
    d0 (0x0010)       "0"
    d1 (0x0011)       "1"
    d2 (0x0012)       "2"
    ...               ...
    d9 (0x0019)       "9"
    da (0x001a)       "A"
    db (0x001b)       "B"
    dc (0x001c)       "C"
    dd (0x001d)       "D"
    ds (0x0020)       "E"
    do (0x0021)       "F"




Clarifications
==========
Section affected: 7.1.5

Comment: if a command other than ServiceChange or Subtract is received for a
terminationID which is in Test or Out of service state, the MG should reject
the command with error 503 - Service unavailable.
Reference: Sachin Mittal, 31/01/00, ServiceChange

Section affected: 7.2.8

Comment: Where the terminationID designates an individual termination the
sender of the ServiceChange command should use the contextID of the context
in which the termination currently lies.  In any other usage the contextID
has no significance for the processing of the ServiceChange command.
Reference: Sachin Mittal, 27/01/00 and Tom Taylor, 31/01/00, Importance of
ContextID in ServiceChange command

Issues Not Yet Resolved
==================

Cisco SG 16: Command Atomicity
So far, comments from Chip Sharp (originator) and Brian Rosen in favour.
I've been told

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 15:56:12 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15481
	for ; Mon, 31 Jan 2000 15:56:11 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.54303390@standards.nortelnetworks.com>; Mon, 31 Jan 2000 15:53:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16458 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 15:53:13 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.47BA32F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          15:53:13 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 14:54:46 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 15:54:14 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LMM2D>; Mon, 31 Jan 2000 15:54:13 -0500
X-Mailer: Internet Mail Service (5.5.2448.0)
Message-ID:  
Date:         Mon, 31 Jan 2000 15:54:04 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Issue Score Card oops
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I accidently dispatched the "Issue Score Card" before I meant to.  It
certainly doesn't cover all the outstanding issues.  What I suggest is that
I put out daily editions, then move items that don't cause any follow-up
discussion to documents which will become TD contributions into Geneva.
I'll keep the TD drafts on the Megaco site.

Tom Taylor
Advisor -- IPConnect Standards
E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 16:47:14 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16456
	for ; Mon, 31 Jan 2000 16:47:12 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.77DF2A10@standards.nortelnetworks.com>; Mon, 31 Jan 2000 16:44:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16508 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 16:43:11 -0500
Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.DCEF4630@standards.nortelnetworks.com>; Mon, 31 Jan 2000 16:33:11
          -0500
Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by
          mailgate.fore.com (8.9.3/8.9.3) with ESMTP id QAA10178; Mon, 31 Jan
          2000 16:35:10 -0500 (EST)
Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221])
          by mailman.fore.com (8.9.3/8.9.3) with ESMTP id QAA26358; Mon, 31 Jan
          2000 16:35:11 -0500 (EST)
Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id
          ; Mon, 31 Jan 2000 16:32:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C32.9C5885F8"
Message-ID:  <4FBEA8857476D311A03300204840E1CF208865@whq-msgusr-02.fore.com>
Date:         Mon, 31 Jan 2000 16:35:09 -0500
Reply-To: "Rosen, Brian" 
Sender: "Media Gateway Control (megaco)"
              
From: "Rosen, Brian" 
Subject:      Re: Cisco SG16: Virtual MG & Root
X-To:         Tom-PT Taylor 
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C32.9C5885F8
Content-Type: text/plain;
        charset="iso-8859-1"

I can't imagine having a situation where the MGC can't tell the MG to at
least warm boot.  Maybe you think
of that as "management".  I'm not very worked up about this issue - I
suspect that when we really implement
Virtual MGs, we will find some issues that need more work.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, January 31, 2000 3:28 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Virtual MG & Root



We're not talking about reboot in the sense of restarting the operating
system -- the operations involved have a much narrower scope.  How strongly
do you feel on this one?

        -----Original Message-----
From:   Rosen, Brian [SMTP:brosen@fore.com]
Sent:   Friday, January 28, 2000 2:28 PM
To:     Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
Subject:        RE: Cisco SG16: Virtual MG & Root

        The problem is Restart of Root.  This is a "warm boot".  If one
Virtual MG does it,
it will happen to all Virtual MGs unless you have a pretty complex
implementation
that can "fake" a warm boot without actually restarting the system.

Brian

        -----Original Message-----
From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com
 ]
Sent: Thursday, January 27, 2000 4:33 PM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Cisco SG16: Virtual MG & Root



        I think this is a reasonable proposal.  When the sentence in
question was placed there, people had visions of one MGC knocking out the
whole (physical) MG.  If we simply interpret ServiceChange to be limited in
scope to the virtual MG, it allows, for instance, an MGC to shed load by
handing over responsibility for that virtual MG to another controller.

                -----Original Message-----
From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
Sent:   Tuesday, January 25, 2000 8:08 PM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Cisco SG16: Virtual MG & Root

                Section:        11.1, second last paragraph
Category:       Technical/Editorial
Issue:          The draft text specifies that "Each virtual MG has its own
Root
Termination" but "ServiceChange may only be applied to the Root by the
Master MGC". The two statements seem to be inconsistent as the purpose of
the virtual MG (and thereby the root termination for that virtual MG) is to
allow the MGC for the virtual MG to control that virtual MG.
Proposal:       It is proposed, that the last sentence is removed since each
virtual MG has its own Root termination.

                v13 Status:     OPEN. No relevant text changed.

                Support NetAid!  < http://www.netaid.org
 >
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------


------_=_NextPart_001_01BF6C32.9C5885F8
Content-Type: text/html;
        charset="iso-8859-1"




RE: Cisco SG16: Virtual MG & Root




        I
can't imagine having a situation where the MGC can't tell the MG to at least
warm boot.  Maybe you think
        

        of
that as "management".  I'm not very worked up about this issue - I suspect
that when we really implement
        

        Virtual MGs, we will find some issues that need more
work.
        

         
        

        Brian
        

        
  
        -----Original Message-----
        From: Tom-PT Taylor
  [mailto:taylor@nortelnetworks.com]
        Sent: Monday, January 31, 2000
  3:28 PM
        To: MEGACO@standards.nortelnetworks.com
        Subject:
  Re: Cisco SG16: Virtual MG & Root

        
  
        We're not talking about reboot in the
  sense of restarting the operating system -- the operations involved have a
  much narrower scope.  How strongly do you feel on this one? 
        
  
          
    
          -----Original Message----- 
          From:   Rosen, Brian [SMTP:brosen@fore.com] 
          Sent:   Friday, January
    28, 2000 2:28 PM 
          To:     Taylor, Tom-PT [CAR:B904:EXCH];
    MEGACO@standards.nortelnetworks.com 
          Subject:        RE: Cisco SG16: Virtual MG & Root 
          
    
          The problem is Restart of
    Root.  This is a "warm boot".  If one Virtual MG does it,
    
          it will happen to all Virtual MGs
    unless you have a pretty complex implementation 
          that can "fake" a warm boot without actually
    restarting the system. 
            
          Brian 
          
    
            
      
            -----Original Message-----
            From: Tom-PT Taylor
      [mailto:taylor@nortelnetworks.com]
            Sent: Thursday, January 27,
      2000 4:33 PM
            To: MEGACO@standards.nortelnetworks.com
            Subject: Re: Cisco
      SG16: Virtual MG & Root

            
      
            I think this is a reasonable
      proposal.  When the sentence in question was placed there, people had
      visions of one MGC knocking out the whole (physical) MG.  If we
      simply interpret ServiceChange to be limited in scope to the virtual MG,
      it allows, for instance, an MGC to shed load by handing over
      responsibility for that virtual MG to another controller.
            
      
                    -----Original Message-----
            From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
            Sent:   Tuesday, January 25, 2000 8:08 PM
            To:    
      MEGACO@STANDARDS.NORTELNETWORKS.COM
            Subject:        Cisco SG16: Virtual MG &
      Root 
            
      
                    Section:        11.1, second
      last paragraph
            Category:      
      Technical/Editorial
            Issue:          The
      draft text specifies that "Each virtual MG has its own Root
            Termination" but
      "ServiceChange may only be applied to the Root by the
            Master MGC". The two
      statements seem to be inconsistent as the purpose of
            the virtual MG (and thereby
      the root termination for that virtual MG) is to
            allow the MGC for the
      virtual MG to control that virtual MG.
            Proposal:       It is proposed, that
      the last sentence is removed since each
            virtual MG has its own Root
      termination. 
            
      
                    v13
      Status:     OPEN. No relevant text
      changed. 
            
      
                    Support NetAid! 
      <http://www.netaid.org>
            --------------------------------------------------
            Chip
      Sharp                
      Consulting Engineering
            Cisco
      Systems             
      Telco Bio-region
            Reality - Love it or Leave it.
            -------------------------------------------------- 
        

------_=_NextPart_001_01BF6C32.9C5885F8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 17:02:22 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16786
	for ; Mon, 31 Jan 2000 17:02:21 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.920DF9A0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 16:59:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16560 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 16:58:13 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.5BEF9AE0@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          16:58:12 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 15:58:20 -0600
Received: from zrchb213.us.nortel.com by zmers013; Mon, 31 Jan 2000 16:58:02
          -0500
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1BKLFTK1>; Mon, 31 Jan 2000 15:58:01 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C36.3DF61738"
Message-ID:  
Date:         Mon, 31 Jan 2000 15:57:59 -0600
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Cisco SG16: Virtual MG & Root
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C36.3DF61738
Content-Type: text/plain

I'd like to follow through on Chip's suggestion, then, and delete the
offending sentence.  Not sure whether to class this as "Erratum" or "Missing
functionality", but I'll try the former.

> -----Original Message-----
> From: Rosen, Brian [SMTP:brosen@fore.com]
> Sent: Monday, January 31, 2000 4:35 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
> Subject:      RE: Cisco SG16: Virtual MG & Root
>
> I can't imagine having a situation where the MGC can't tell the MG to at
> least warm boot.  Maybe you think
> of that as "management".  I'm not very worked up about this issue - I
> suspect that when we really implement
> Virtual MGs, we will find some issues that need more work.
>
> Brian
>
>       -----Original Message-----
>       From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
>       Sent: Monday, January 31, 2000 3:28 PM
>       To: MEGACO@standards.nortelnetworks.com
>       Subject: Re: Cisco SG16: Virtual MG & Root
>
>
>
>       We're not talking about reboot in the sense of restarting the
> operating system -- the operations involved have a much narrower scope.
> How strongly do you feel on this one?
>
>               -----Original Message-----
>       From:   Rosen, Brian [SMTP:brosen@fore.com]
>       Sent:   Friday, January 28, 2000 2:28 PM
>       To:     Taylor, Tom-PT [CAR:B904:EXCH];
> MEGACO@standards.nortelnetworks.com
>       Subject:        RE: Cisco SG16: Virtual MG & Root
>
>               The problem is Restart of Root.  This is a "warm boot".  If
> one Virtual MG does it,
>       it will happen to all Virtual MGs unless you have a pretty complex
> implementation
>       that can "fake" a warm boot without actually restarting the system.
>
>       Brian
>
>                       -----Original Message-----
>               From: Tom-PT Taylor [ ]
>               Sent: Thursday, January 27, 2000 4:33 PM
>               To: MEGACO@standards.nortelnetworks.com
>               Subject: Re: Cisco SG16: Virtual MG & Root
>
>
>
>                       I think this is a reasonable proposal.  When the
> sentence in question was placed there, people had visions of one MGC
> knocking out the whole (physical) MG.  If we simply interpret
> ServiceChange to be limited in scope to the virtual MG, it allows, for
> instance, an MGC to shed load by handing over responsibility for that
> virtual MG to another controller.
>
>                               -----Original Message-----
>               From:   Chip Sharp [SMTP:chsharp@CISCO.COM]
>               Sent:   Tuesday, January 25, 2000 8:08 PM
>               To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
>               Subject:        Cisco SG16: Virtual MG & Root
>
>                               Section:        11.1, second last paragraph
>               Category:       Technical/Editorial
>               Issue:          The draft text specifies that "Each virtual
> MG has its own Root
>               Termination" but "ServiceChange may only be applied to the
> Root by the
>               Master MGC". The two statements seem to be inconsistent as
> the purpose of
>               the virtual MG (and thereby the root termination for that
> virtual MG) is to
>               allow the MGC for the virtual MG to control that virtual MG.
>               Proposal:       It is proposed, that the last sentence is
> removed since each
>               virtual MG has its own Root termination.
>
>                               v13 Status:     OPEN. No relevant text
> changed.
>
>                               Support NetAid!  < >
>               --------------------------------------------------
>               Chip Sharp                 Consulting Engineering
>               Cisco Systems              Telco Bio-region
>               Reality - Love it or Leave it.
>               --------------------------------------------------
>

------_=_NextPart_001_01BF6C36.3DF61738
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable






RE: Cisco SG16: Virtual MG & Root




        I'd like to follow =
through on Chip's suggestion, then, and delete the offending =
sentence.  Not sure whether to class this as "Erratum" =
or "Missing functionality", but I'll try the =
former.
        

          

          -----Original Message-----

          From:   Rosen, Brian [SMTP:brosen@fore.com]

          Sent:   Monday, January 31, 2000 4:35 PM

          To:     Taylor, Tom-PT [CAR:B904:EXCH]; =
MEGACO@standards.nortelnetworks.com

          Subject:       =
 RE: Cisco SG16: Virtual MG & =
Root

          


          I can't imagine =
having a situation where the MGC can't tell the MG to at least warm =
boot.=A0 Maybe you think

          of that as =
"management".=A0 I'm not very worked up about this issue - I =
suspect that when we really implement

          Virtual MGs, we =
will find some issues that need more work.

          =A0

          Brian

          

            

            -----Original Message-----
            
            From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c=
om]
            
            Sent: Monday, January 31, 2000 3:28 PM
            
            To: MEGACO@standards.nortelnetworks.com
            
            Subject: Re: Cisco SG16: Virtual MG & Root
            

            
            

            


            We're not talking =
about reboot in the sense of restarting the operating system -- the =
operations involved have a much narrower scope.=A0 How strongly do you =
feel on this one? 
            


                    -----Original Message-----
            
            From:=A0=A0 Rosen, Brian =
[SMTP:brosen@fore.com]
            
            Sent:=A0=A0 Friday, January =
28, 2000 2:28 PM
            
            To:=A0=A0=A0=A0 Taylor, Tom-PT =
[CAR:B904:EXCH]; MEGACO@standards.nortelnetworks.com
            
            Subject:=A0=A0=A0=A0=A0=A0=A0 RE: Cisco SG16: =
Virtual MG & Root 

            


                    The problem is Restart of Root.=A0 This is a =
"warm boot".=A0 If one Virtual MG does it,
            
            it will happen =
to all Virtual MGs unless you have a pretty complex =
implementation
            
            that can =
"fake" a warm boot without actually restarting the =
system.
            
=A0
            
            Brian 

            

              

                      -----Original Message-----
              
              From: Tom-PT Taylor [ <mailto:taylor@nortelnetworks.c=
om>]
              
              Sent: Thursday, January 27, 2000 4:33 PM
              
              To: MEGACO@standards.nortelnetworks.com
              
              Subject: Re: Cisco SG16: Virtual MG & Root
              

              
              

              


                      I think this is a reasonable proposal.=A0 When =
the sentence in question was placed there, people had visions of one =
MGC knocking out the whole (physical) MG.=A0 If we simply interpret =
ServiceChange to be limited in scope to the virtual MG, it allows, for =
instance, an MGC to shed load by handing over responsibility for that =
virtual MG to another controller.
              


                      =A0=A0=A0=A0=A0=A0=A0 -----Original Message-----
              
From:=A0=A0 Chip Sharp =
[SMTP:chsharp@CISCO.COM]
              
Sent:=A0=A0 Tuesday, January =
25, 2000 8:08 PM
              
To:=A0=A0=A0=A0 MEGACO@STANDARDS.NORTELNETWORKS.COM
              
Subject:=A0=A0=A0=A0=A0=A0=A0 Cisco SG16: =
Virtual MG & Root 

              


                      =A0=A0=A0=A0=A0=A0=A0 Section:=A0=A0=A0=A0=A0=A0=A0 11.1, second last =
paragraph
              
Category:=A0=A0=A0=A0=A0=A0 =
Technical/Editorial
              
Issue:=A0=A0=A0=A0=A0=A0=A0=A0=A0 The =
draft text specifies that "Each virtual MG has its own =
Root
              
Termination" but "ServiceChange =
may only be applied to the Root by the
              
Master MGC". The two statements seem =
to be inconsistent as the purpose of
              
the virtual MG (and thereby the root =
termination for that virtual MG) is to
              
allow the MGC for the virtual MG to =
control that virtual MG.
              
Proposal:=A0=A0=A0=A0=A0=A0 It is =
proposed, that the last sentence is removed since each
              
virtual MG has its own Root =
termination. 

              


                      =A0=A0=A0=A0=A0=A0=A0 v13 Status:=A0=A0=A0=A0 OPEN. No relevant text =
changed. 

              


                      =A0=A0=A0=A0=A0=A0=A0 Support NetAid!=A0 < <http://www.netaid.org>>
              
--------------------------------------------------=

              
Chip =
Sharp=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Consulting =
Engineering
              
Cisco =
Systems=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Telco =
Bio-region
              
Reality - Love it or Leave it.
              
--------------------------------------------------=
 

              

        


------_=_NextPart_001_01BF6C36.3DF61738--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 17:29:27 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17180
	for ; Mon, 31 Jan 2000 17:29:27 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A5500E0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 17:26:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16608 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 17:25:06 -0500
Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.1D9517D0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 17:25:06
          -0500
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id
          RAA16485 for ; Mon, 31 Jan 2000
          17:22:04 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76),
          claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by
          ns01.newbridge.com, id smtpdAAASLc3z_; Mon Jan 31 17:21:56 2000
Received: from [138.120.49.10] by kanata-mh1.ca.newbridge.com with ESMTP for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 17:26:57 -0500
Received: (from smap@localhost) by affserver.ca.newbridge.com. (8.8.5/8.8.5) id
          RAA06557 for ; Mon, 31 Jan 2000
          17:27:11 -0500 (EST)
Received: from unknown(192.168.150.1) by affserver via smap (V1.3) id
          sma006555; Mon Jan 31 17:26:59 2000
Received: from bridgewatersys.com by bridgewatersys.com (SMI-8.6/SMI-SVR4) id
          RAA12403; Mon, 31 Jan 2000 17:25:19 -0500
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: 
Content-Type: multipart/mixed; boundary="------------4C6C3F74E2BD8D3F5BF6FFF2"
Message-ID:  <38960E5E.242E2E46@bridgewatersys.com>
Date:         Mon, 31 Jan 2000 17:36:14 -0500
Reply-To: Goutam Shaw 
Sender: "Media Gateway Control (megaco)"
              
From: Goutam Shaw 
Organization: Bridgewater Systems Corp.
Subject:      Re: NAS and Calling/Called Numbers.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------4C6C3F74E2BD8D3F5BF6FFF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> Yair Arian wrote:
>
> Hi,
>   When the MG is a NAS and the Calling/Called numbers arrive at the MGC via the Signaling Network (SS7), how does
> the MGC convey these numbers to the NAS?  These numbers are needed for authentication performed via the RADIUS by
> the NAS and for other purposes.
> Yair Arian.
> G-Connect Ltd.

This would depend on the definition of the NAS package. Although the MEGACO requirements document (v10 section 11.2.5
f) does impose the requirement that the calling/called party numbers be forwarded to the MG from MGC.

...Goutam.

--------------4C6C3F74E2BD8D3F5BF6FFF2
Content-Type: text/x-vcard; charset=us-ascii;
 name="goutam.shaw.vcf"
Content-Description: Card for Goutam Shaw
Content-Disposition: attachment;
 filename="goutam.shaw.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Shaw;Goutam
x-mozilla-html:FALSE
org:Bridgewater Systems Corp.
adr:;;800-555 Legget Dr.;Ottawa;Ontario;K1G5J7;Canada
version:2.1
email;internet:goutam.shaw@bridgewatersys.com
title:Product Manager
tel;fax:613-591-6656
tel;work:613-591-6655 x2796
x-mozilla-cpt:;0
fn:Goutam  Shaw
end:vcard

--------------4C6C3F74E2BD8D3F5BF6FFF2--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 18:50:35 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18541
	for ; Mon, 31 Jan 2000 18:50:35 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B464E090@standards.nortelnetworks.com>; Mon, 31 Jan 2000 18:48:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16811 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 18:46:47 -0500
Received: from smtprch1.nortel.com (192.135.215.14) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.86DC8920@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          18:46:47 -0500
Received: from zmers013 by smtprch1.nortel.com; Mon, 31 Jan 2000 17:46:24 -0600
Received: from zrtpd004.us.nortel.com (actually nrtpd004) by zmers013; Mon, 31
          Jan 2000 18:46:09 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2448.0) id
          <1A9LMQ2K>; Mon, 31 Jan 2000 18:46:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C45.5768AFC8"
Message-ID:  
Date:         Mon, 31 Jan 2000 18:46:06 -0500
Reply-To: Tom-PT Taylor 
Sender: "Media Gateway Control (megaco)"
              
From: Tom-PT Taylor 
Subject:      Re: Summary of $, *, MOVE, ServiceChange
X-To:         bmbabu@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C45.5768AFC8
Content-Type: text/plain

Most of point 1 looks like good practice, and we probably follow it at this
point.  I'm not too happy about any suggestion that the MG doesn't have to
look at the media descriptor when allocating ephemerals, and saying that
foo$ always means a provisioned termination is also probably too
restrictive.  Later discussion in the thread "Choosing of ephemeral /
physical Termination" gives examples where that latter convention in
particular is undesirable.

We have also discussed when contextID is significant and when it is not.  We
can spell this out further, but it's definitely in the "clarifications"
category.

> -----Original Message-----
> From: Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]
> Sent: Friday, January 28, 2000 1:26 AM
> To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject:      Summary of $, *, MOVE, ServiceChange
>
> I suggest that we should adopt this practice:
> 1. The special values $, * both for contexts and terminations have defined
> meaning that
> is not dictated by the command functionality they appear in:
> ContextID * means ALL contexts (not ANY context in some cases as SUBTRACT
> C=*
> T=foo*,or T=*, or T=specified)
> ContextID $ means ALLOCATE a new one (not FIND a context as in SUBTRACT
> C=$ T=
> ... as above...)
> TermID * means ALL terminations
> TermID $ means ALLOCATE ephemeral (Don't look at media descriptor)
> TermID foo* means ALL that START with foo
> TermID foo$ means CHOOSE a physical (Don't look at media descriptor)
>
> 2. Some commands are termination oriented and the appearance of contextID
> doesn't
> carry any meaning. No validation of contextID should be done for these
> commands
> These are ServiceChange and Audit (Auditing termination whether in context
> or
> not)
> (Subtract ??? For Subtract the only meaning
> of context is NULL or non-NULL. specific contextID do not have a meaning
> because
> a
> termination belongs to a single context and subtraction is moving to NULL
> from
> that single context.
> specific contextID is used by MGC only to help MG easily locate the
> context or
> may be for
> more commands for the same context.)
>
> 3. ADD and MOVE are related to both termination and context.
>
> (what about other commands ???)
>
> Madhu
> Sachin
> Hughes Software Systems

------_=_NextPart_001_01BF6C45.5768AFC8
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable






RE: Summary of $, *, MOVE, ServiceChange




        Most of point 1 =
looks like good practice, and we probably follow it at this =
point.  I'm not too happy about any suggestion that the MG doesn't =
have to look at the media descriptor when allocating ephemerals, and =
saying that foo$ always means a provisioned termination is also =
probably too restrictive.  Later discussion in the thread =
"Choosing of ephemeral / physical Termination" gives examples =
where that latter convention in particular is undesirable.
        


        We have also =
discussed when contextID is significant and when it is not.  We =
can spell this out further, but it's definitely in the =
"clarifications" category.
        

          

          -----Original Message-----

          From:   Madhu Babu [SMTP:bmbabu@HSS.HNS.COM]

          Sent:   Friday, January 28, 2000 1:26 AM

          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM

          Subject:       =
 Summary of $, *, MOVE, =
ServiceChange

          


          I suggest that we should adopt this =
practice:

          1. The special values $, * both for =
contexts and terminations have defined

          meaning that

          is not dictated by the command =
functionality they appear in:

          ContextID * means ALL contexts (not =
ANY context in some cases as SUBTRACT C=3D*

          T=3Dfoo*,or T=3D*, or =
T=3Dspecified)

          ContextID $ means ALLOCATE a new one =
(not FIND a context as in SUBTRACT C=3D$ T=3D

          ... as above...)

          TermID * means ALL =
terminations

          TermID $ means ALLOCATE ephemeral =
(Don't look at media descriptor)

          TermID foo* means ALL that START with =
foo

          TermID foo$ means CHOOSE a physical =
(Don't look at media descriptor)

          


          2. Some commands are termination =
oriented and the appearance of contextID

          doesn't

          carry any meaning. No validation of =
contextID should be done for these commands

          These are ServiceChange and Audit =
(Auditing termination whether in context or

          not)

          (Subtract ??? For Subtract the only =
meaning

          of context is NULL or non-NULL. =
specific contextID do not have a meaning because

          a

          termination belongs to a single =
context and subtraction is moving to NULL from

          that single context.

          specific contextID is used by MGC =
only to help MG easily locate the context or

          may be for

          more commands for the same =
context.)

          


          3. ADD and MOVE are related to both =
termination and context.

          


          (what about other commands ???)

          


          Madhu

          Sachin

          Hughes Software Systems

          

        


------_=_NextPart_001_01BF6C45.5768AFC8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 19:08:45 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18728
	for ; Mon, 31 Jan 2000 19:08:44 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.392AD3F0@standards.nortelnetworks.com>; Mon, 31 Jan 2000 19:06:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16829 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 19:04:14 -0500
Received: from black.coppercom.com (204.247.206.20) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP
          id <0.F6B7B830@standards.nortelnetworks.com>; Mon, 31 Jan 2000
          19:04:13 -0500
Received: by black.int.coppercom.com with Internet Mail Service (5.5.2448.0) id
          ; Mon, 31 Jan 2000 16:04:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01BF6C47.E56F8B10"
Message-ID:  
Date:         Mon, 31 Jan 2000 16:04:23 -0800
Reply-To: Murat Bog 
Sender: "Media Gateway Control (megaco)"
              
From: Murat Bog 
Subject:      Re: FW: Re: Stopping of Dial Tone
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF6C47.E56F8B10
Content-Type: text/plain;
        charset="iso-8859-1"

Unless I have missed some obvious points, I don't see this as a non-issue
and I share the concern with Madhu Babu.  Although we all know what the
desired behavior is, neither the current definition of the ce event in the
dd package nor that of the DigitMap descriptor in section 7.1.14 supports
that behavior.  The dd/ce event is detected by the MG when the digits/timers
match the dial plan.  We want the dial tone to stop immediately after the
detection of the first digit.  At that time, however, there is no match
against the dial plan (unless the dial plan is something like "x") and a
dd/ce event which should stop the dial tone does not exist yet.

I don't know of any other place in the protocol specification where this
issue is explicitly addressed.  The ABNF changes regarding the event
descriptor, introduced in v13 and retained in v14, show the eventDM as
possible a parameter of a requestedEvent, but nothing is said about the
handling of signals if eventDM is used; i.e. stop signals after the first
digit.  If this were the intent, I think it should be made explicit in the
text.  If not, I am not sure it would be a good idea to change the
definition of dd/ce event to the same effect since it would create an
exception to the general model.

It also seems to me that there may be other ways of expressing the desired
behaviour.  One example that I remember have been discussed on the list
before used the embedding capability as follows (assume event buffering is
off):

Events = 2223 {
  al/on,
  dd/etd {
     tl = *,
     Embed {
       Events = 2224 {
         dd/ce {
            DigitMap = DialPlan0
         }
     }
  }
}
Signals {
  cg/dt
}

I am assuming that if embedding is used in a requestedEvent, the processing
is such that a notify command is not sent when that event is detected but
rather the event is applied against the embedded event descriptor (if there
is one).  Otherwise, two notify commands will be sent: one when the first
digit is detected and the second when the following digits/timers match the
digit map.  This may or may not be the desired behavior but in any case this
could be another area for the text to benefit from some clarification.


Murat Bog.
CopperCom Inc.

 -----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Monday, January 31, 2000 6:52 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: FW: Re: Stopping of Dial Tone



I'm happy to accept this as the common understanding.

        -----Original Message-----
From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM]
Sent:   Monday, January 31, 2000 8:17 AM
To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:        Re: FW: Re: Stopping of Dial Tone

        John,

        This was also my working assumption and I agree that I don't really
see this as
a problem either.

        -Selvam Rengasami
Telcordia Technologies

        Tel:  +1 732 758 5260
E-mail:  srengasa@telcordia.com





        John Segers  on 01/31/2000 06:33:41 AM

        Please respond to John Segers 

        To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Selvam Rengasami/Telcordia)
Subject:  Re: FW: Re: Stopping of Dial Tone




        Tom,

        Is it really a problem?  The way I always understood this, is that
detection of an event stops an active signal.  It doesn't matter how the
event is detected or reported.  So an event that leads to a partial
match in a digit map (the first digit) would stop dialtone.

        Is my thinking flawed?

        John

        Tom-PT Taylor wrote:
>
> Resend -- first attempt got swallowed.
>
> > -----Original Message-----
> > From: Taylor, Tom-PT [CAR:B904:EXCH]
> > Sent: Wednesday, January 26, 2000 12:46 PM
> > To:   'Megaco'
> > Subject:      Re: Stopping of Dial Tone
> >
> > The problem is real.  The question is what event detection mechanism to
> > use to stop dial tone.  It doesn't matter whether we define a new start
of
> > dialling event or simply use the existing dd/* ("detect any DTMF
digit"):
> > there is a problem of potential interaction with the digit map.  The
most
> > straightforward solution is that the MGC has to ask that the first digit

> > be reported, and only after that it can send down a digit map for
> > everything else.  Alternatively we have to modify section 7.1.8 to make
it
> > clear that it is possible to request digit detection in parallel with
> > digit mapping (i.e. dd/* in combination with dd/ce {...} means that
> > individual digit events are detected, but the same digits are also
> > processed by the digit map.
> >
> > Comments?
> >
> >
> >                     From:         Madhu Babu 
> >                     Subject:      Stopping of Dial tone
> >
> >
> >                     Hi all,
> >
> >                     According to the example in the Appendix A.1.2 when
> > MGC request
> >                     MG to apply dial tone and check for digit events it
is
> > specified
> >                     as
> >
> >                     Events = 2223 {
> >                     al/on, dd/ce {DigitMap=Dialplan0}
> >                     }
> >                     Signals {cg/dt},
> >
> >                     According to the protocol an signal is stopped
> > Whenever any
> >                     event occurs. and here the event requested by MGC is

> > digitmap
> >                     completion,that means dial tone will be stopped when

> > we get
> >                     all the digits (as implied by the name digitmap
> > completion).
> >                     What I suggest is that a new event like
> > "firstdigitcompletion"
> >                     should also  be specified, otherwise how can the
first
> > digit itself
> >                     stops the dialtone.
> >
> >                     regards
> >                     -Madhubabu
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961
> >

        --
John Segers                                  email: jsegers@lucent.com
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954


------_=_NextPart_001_01BF6C47.E56F8B10
Content-Type: text/html;
        charset="iso-8859-1"




RE: FW: Re: Stopping of Dial Tone




        Unless
I have missed some obvious points, I don't see this as a non-issue and I share
the concern with Madhu Babu.  Although we all know what the desired
behavior is, neither the current definition of the ce event in the dd package
nor that of the DigitMap descriptor in section 7.1.14 supports that
behavior.  The dd/ce event is detected by the MG when the
digits/timers match the dial plan.  We want the dial tone to stop
immediately after the detection of the first digit.  At that time, however,
there is no match against the dial plan (unless the dial plan is something
like "x") and a dd/ce event which should stop the dial tone does not exist
yet.
        

         
        

        I
don't know of any other place in the protocol specification where this issue is
explicitly addressed.  The ABNF changes regarding the event descriptor,
introduced in v13 and retained in v14, show the eventDM as possible a
parameter of a requestedEvent, but nothing is said about the handling of signals
if eventDM is used; i.e. stop signals after the first digit.  If this were
the intent, I think it should be made explicit in the text.  If not, I
am not sure it would be a good idea to change the definition of dd/ce event
to the same effect since it would create an exception to the general
model.
        

         
        

        It
also seems to me that there may be other ways of expressing the desired
behaviour.  One example that I remember have been discussed on the list
before used the embedding capability as follows (assume event buffering is
off):
        

         
        

        Events = 2223 { 
        

         
al/on,
        

          dd/etd
{
        

             tl = *,
        

             Embed
{
        

               Events = 2224
{
        

                 dd/ce
{
        

                   
DigitMap = DialPlan0
        

                
}
        

             }
          }
        

        }
        

        Signals
{
        

          cg/dt
        

        } 
        

         
        

        I am
assuming that if embedding is used in a requestedEvent, the processing is such
that a notify command is not sent when that event is detected but rather
the event is applied against the embedded event descriptor (if there is
one).  Otherwise, two notify commands will be sent: one when the first
digit is detected and the second when the following digits/timers match the
digit map.  This may or may not be the desired behavior but in any case
this could be another area for the text to benefit from some
clarification.
        

         
        

         
        

        Murat
Bog.
        

        CopperCom Inc.
        

         
        

         -----Original Message-----
        From:
Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
        Sent: Monday, January
31, 2000 6:52 AM
        To:
MEGACO@STANDARDS.NORTELNETWORKS.COM
        Subject: Re: FW: Re: Stopping of
Dial Tone

        

        
  
        I'm happy to accept this as the
  common understanding. 
        
  
          
    
          -----Original Message----- 
          From:   Selvam Rengasami [SMTP:srengasa@TELCORDIA.COM] 
          Sent:   Monday, January 31, 2000 8:17 AM 
          To:     MEGACO@STANDARDS.NORTELNETWORKS.COM 
          Subject:        Re: FW: Re: Stopping of Dial Tone 
          
    
          John, 
          
    
          This was also my working assumption and I agree
    that I don't really see this as 
          a problem
    either. 
          
    
          -Selvam Rengasami 
          Telcordia Technologies 
          
    
          Tel:  +1 732 758 5260 
          E-mail:  srengasa@telcordia.com
    




          
    
          John Segers <jsegers@LUCENT.COM> on
    01/31/2000 06:33:41 AM 
          
    
          Please respond to John Segers
    <jsegers@LUCENT.COM> 
          
    
          To:  
    MEGACO@STANDARDS.NORTELNETWORKS.COM 
          cc:    (bcc: Selvam Rengasami/Telcordia)
    
          Subject:  Re: FW: Re: Stopping of Dial
    Tone 



          
    
          Tom, 
          
    
          Is it really a problem?  The way I always
    understood this, is that 
          detection of an
    event stops an active signal.  It doesn't matter how the
    
          event is detected or reported.  So an event
    that leads to a partial 
          match in a digit
    map (the first digit) would stop dialtone. 
          
    
          Is my thinking flawed? 
          
    
          John 
          
    
          Tom-PT Taylor wrote: 
          > 
          > Resend -- first attempt
    got swallowed. 
          > 
          > > -----Original Message----- 
          > > From: Taylor, Tom-PT [CAR:B904:EXCH]
    
          > > Sent: Wednesday, January 26, 2000
    12:46 PM 
          > > To:  
    'Megaco' 
          > >
    Subject:      Re: Stopping of Dial Tone
    
          > > 
          > > The problem is real.  The question is what event
    detection mechanism to 
          > > use to
    stop dial tone.  It doesn't matter whether we define a new start
    of 
          > > dialling event or simply use
    the existing dd/* ("detect any DTMF digit"): 
          > > there is a problem of potential interaction with the digit
    map.  The most 
          > >
    straightforward solution is that the MGC has to ask that the first
    digit 
          > > be reported, and only
    after that it can send down a digit map for 
          > > everything else.  Alternatively we have to modify
    section 7.1.8 to make it 
          > > clear
    that it is possible to request digit detection in parallel with
    
          > > digit mapping (i.e. dd/* in
    combination with dd/ce {...} means that 
          > > individual digit events are detected, but the same digits
    are also 
          > > processed by the digit
    map. 
          > > 
          > > Comments? 
          > > 
          > >
    
          >
    >                    
    From:         Madhu Babu
    <bmbabu@HSS.HNS.COM> 
          >
    >                    
    Subject:      Stopping of Dial tone
    
          > > 
          > > 
          >
    >                    
    Hi all, 
          > > 
          >
    >                    
    According to the example in the Appendix A.1.2 when 
          > > MGC request 
          >
    >                    
    MG to apply dial tone and check for digit events it is 
          > > specified 
          >
    >                    
    as 
          > > 
          >
    >                    
    Events = 2223 { 
          >
    >                    
    al/on, dd/ce {DigitMap=Dialplan0} 
          >
    >                    
    } 
          >
    >                    
    Signals {cg/dt}, 
          > >
    
          >
    >                    
    According to the protocol an signal is stopped 
          > > Whenever any 
          >
    >                    
    event occurs. and here the event requested by MGC is 
          > > digitmap 
          >
    >                    
    completion,that means dial tone will be stopped when 
          > > we get 
          >
    >                    
    all the digits (as implied by the name digitmap 
          > > completion). 
          >
    >                    
    What I suggest is that a new event like 
          > > "firstdigitcompletion" 
          >
    >                    
    should also  be specified, otherwise how can the first 
          > > digit itself 
          >
    >                    
    stops the dialtone. 
          > >
    
          >
    >                    
    regards 
          >
    >                    
    -Madhubabu 
          > > 
          > > Tom Taylor 
          > > Advisor -- IPConnect Standards 
          > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT
    Taylor) 
          > > Phone and FAX: +1 613
    736 0961 
          > > 
          
    
          -- 
          John
    Segers                                 
    email: jsegers@lucent.com 
          Lucent
    Technologies                                       
    Room HE 306 
          Dept. Forward Looking
    Work                     
    phone: +31 35 687 4724 
          P.O. Box 18, 1270
    AA 
    Huizen                     
    fax: +31 35 687 5954 
        

------_=_NextPart_001_01BF6C47.E56F8B10--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Jan 31 23:10:08 2000
Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23494
	for ; Mon, 31 Jan 2000 23:10:08 -0500 (EST)
Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EA3F7530@standards.nortelnetworks.com>; Mon, 31 Jan 2000 23:07:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16969 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 31 Jan 2000 23:06:06 -0500
Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1a) with SMTP id
          <0.B1772C20@standards.nortelnetworks.com>; Mon, 31 Jan 2000 23:05:40
          -0500
Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by
          tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA01865 for
          ; Tue, 1 Feb 2000 10:06:01 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          65256878.00161970 ; Tue, 1 Feb 2000 09:31:23 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <65256878.001611EF.00@sandesh.hss.hns.com>
Date:         Tue, 1 Feb 2000 09:34:31 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"
              
From: Sachin Mittal 
Subject:      Re: Choosing of ephemeral / physical Termination.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Christian,
if MGC is aware of patterns of such kind, then
the issues/assumptions are as mentioned by Brian
But the original point was the the appearance
of $ with NO PRE-STRING and POST-STRING attached to it.
In that case how can you figure out what to choose.
I am not in favor of looking at media descriptor, etc
because they may not appear with the ADD.
Can we say ADD is successful if there doesn't yet
exist a "star connection" in the context in which atleast
one other termination is present ???





"Rosen, Brian"  on 02/01/2000 01:09:49 AM

Please respond to "Rosen, Brian" 

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Mittal/HSS)

Subject:  Re: Choosing of ephemeral / physical Termination.




Just checking my assumptions:
        For a physical termination, you want to be able to say:
                MyDS3/3/$
       meaning, you choose any DS0 you want in the 3rd DS1 of a DS3,
assuming that
         was how my MG named the DS0s (such a structure NOT being required).
Could
        I also ask for MyDS3/$/$?

        For an ephemeral termination, suppose that I knew, by discovery or
        provisioning that RTP bearers were named RTP/nnnn and ATM bearers
were
        named AAL1/nnnn/nn.  Can I Add=AAL1/0003/$, which means create an
        ephemeral for an ATM AAL1 bearer, with the MG choosing the
subchannel?

Brian

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, January 31, 2000 10:27 AM
> To: MEGACO@standards.nortelnetworks.com
> Subject: Re: Choosing of ephemeral / physical Termination.
>
>
> Hello all,
>
> I believe that we have diverged from the first email in this
> thread. We
> do not need rules to determine what media and bearer is instantiated.
>
> For a physical termination a certain terminationID schema will be
> assigned by the MG. ie. /myscheme/physical/trunk/circuit
> If the MGC wanted to CHOOSE a physical termination it could either
> wildcard 'trunk' or 'circuit'.
>
> For a emphemeral terminatoion a certain terminationID schema will be
> assigned by the MG. The MGC by various means would be aware of this
> scheme.
> ie. /myscheme/euphemeral/IP
> If the MGC wanted to CHOOSE a euphemeral termination it could wilcard
> the 'IP'
>
> The 'physical' and 'ephemeral' could be anything in the the
> MG assigned
> scheme that would differentiate the two.
>
> If the MGC doesn't care which one then it CHOOSES on the
> 'ephemeral'/'physical' level. The MG can determine which one to return
> from ANY information in the media descriptors. This is
> something for the
> MG to decide, not something that needs to be specified in
> rules in H248
> because they'll probably change according to your
> application, resource
> allocation algorithms in the MG, etc. I do agree that an
> error should be
> returned if the MG cannot determine the terminationID.
>
> I think the scope of this is also limited to the ADD command. The ADD
> will return a fully specified terminationID which can then be
> referenced
> in Move, Modify, Subtract etc.
>
> Regards, Christian
>
> Tom-PT Taylor wrote:
> >
> > Right, we haven't converged yet.  I have a suggestion which may
> > resolve this, that we add these rules
> >
> > (1) If the MGC provides too little information in an Add command for
> > the MG to select the bearer type for that termination, the MG must
> > reject the command with [appropriate error].  In practice,
> this means
> > either that the terminationID in the command provides the necessary
> > information, or else that at least one instance of a Local or Remote
> > descriptor must be present, containing a c= line with a specified
> > nettype (or the Annex C equivalent).
> >
> > (2) If the MGC provides too little information in an Add, Move, or
> > Modify command for the MG to determine the medium to be carried in a
> > given stream, the MG must reject the command with [appropriate
> > error].  The MG has three ways to determine medium:
> >
> >  - streamID unspecified defaults to streamID=1 and medium=audio
> >  - medium has already been specified for that streamID for another
> > termination in the same context
> >  - explicit specification of medium in an m= line (or the Annex C
> > equivalent) in an instance of Local or Remote for the given
> streamID.
> >
> >      -----Original Message-----
> >      From:   Rosen, Brian [SMTP:brosen@FORE.COM]
> >      Sent:   Monday, January 31, 2000 9:15 AM
> >      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      Subject:        Re: Choosing of ephemeral / physical
> Termination.
> >
> >      I believe we have not reached consensus on this issue, so I did
> >      not
> >      change the text.  Tom, is that your view?
> >
> >      Brian
> >
> >      > -----Original Message-----
> >      > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > Sent: Monday, January 31, 2000 2:52 AM
> >      > To: MEGACO@standards.nortelnetworks.com
> >      > Subject: Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      > The point that "$" is for choosing ephemeral is not yet added
> >      > in V14. Is it that
> >      > the discussion
> >      > is not yet complete? What about foo$ representing choose
> >      physical.
> >      >
> >      >
> >      >
> >      >
> >      > Sachin Mittal  on 01/27/2000 11:35:50 AM
> >      >
> >      > Please respond to samittal@hns.com
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Its true that the type of termination should not be
> >      > identified by looking into
> >      > the descriptor
> >      > information. Somewhere in the text this should be added that
> >      > " $ if it appears
> >      > alone indicates
> >      > ephemeral termination and partial $ (ex foo$) indicates
> >      > selection of a physical
> >      > termination
> >      > (a circuit within a trunk group)".
> >      >
> >      >
> >      >
> >      >
> >      > "Rosen, Brian"  on 01/27/2000 02:36:46 AM
> >      >
> >      > Please respond to "Rosen, Brian" 
> >      >
> >      > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> >      > cc:    (bcc: Sachin Mittal/HSS)
> >      >
> >      > Subject:  Re: Choosing of ephemeral / physical Termination.
> >      >
> >      >
> >      >
> >      >
> >      > Generally determined by the "kind" of termination requested.
> >      > Which is in turn, easily discernable from the Media command.
> >      >
> >      > However, upon reflection, I think it's not a good answer.
> >      > I'd propose that we not allow selection of a physical
> >      termination,
> >      > in which case choose is always create an ephemeral.  In
> >      particular,
> >      > the following is perfectly legal:
> >      > Context=${Add=${}}
> >      > What do you get?
> >      >
> >      > Brian
> >      >
> >      > > -----Original Message-----
> >      > > From: Sachin Mittal [mailto:samittal@hss.hns.com]
> >      > > Sent: Tuesday, January 25, 2000 9:01 AM
> >      > > To: MEGACO@standards.nortelnetworks.com
> >      > > Subject: Choosing of ephemeral / physical Termination.
> >      > >
> >      > >
> >      > > Annex B.1 says that "The CHOOSE TerminationID $ may be used
> >      > > to signal to the MG
> >      > > that it has to create an
> >      > > ephemeral Termination or select an idle physical
> >      Termination".
> >      > > How can MG determine when to create an ephemeral
> termination
> >      > > and when to choose
> >      > > idle physical termination.??
> >      > > What is the logic behind this decision making?
> >      > >
> >      > > regards
> >      > > -Sachin Mittal
> >      > >
> >      >
>