Subject: AW: Packages Conference Call Minutes

From: Bilalis Zacharias <[email-masked]>
Date: Wed, 6 Oct 1999 16:33:22 +0200

Referring to the Conference Call of 4th October, please find attached the
proposed solution.

 <<megaco-basicpkg.txt>>

Best Regards

Zacharias Bilalis

SIEMENS ICN WN CS EC D12
> Schertlinstr. 8
> D-81359 Muenchen
> Germany
Tel: + 49 89 722 28391
Fax: + 49 89 722 61243
Mail to: [email-masked]

> 4. Handling of tones and other extensible lists of parameter values
>
> Tones in particular are problematic, in that not all MGs (or even MGCs)
> should implement every tone.  It was also recognized that an MG may have a
> requirement to be able to play a tone, but no need to detect it, or vice
> versa.
>
> To start with, it was agreed that a small set of basic events and signals
> would be defined to play and detect tones.  The identity of the tone to be
> played or detected would appear as a parameter of the event or signal.
>
> We discussed methods of organizing tones within packages to meet the
> requirements.  One possibility is to define packages whose content would
> consist solely of a list of tone names to be played out or detected.  Mike
> Kallas asked for the chance for his drafting team to come up with a
> solution.
>
> ***Action: Mike Kallas and Zacharias Bilalis to publish a proposed
> solution
> to the list by the end of Wednesday.
> ***Action: Tom Taylor to organize a follow-up conference call to begin
> Thursday at 10:00 am EDT (4:00 pm German time, 8:00 am MDT, 9:00 am CDT).
>
> It was noted that this requirement may apply to other events and signals
> besides tones.  (I believe I had an example I considered a few days ago,
> but
> I've forgotten what it was.)
> ***Action: The list is asked to indicate whether this is so.
>
>
>
> Tom Taylor
> Advisor -- IPConnect Standards
> E-mail: [email-masked] (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961

---

From: Chip Sharp <[email-masked]>
Date: Wed, 6 Oct 1999 13:32:59 -0400

It is hard to reconcile the NAS part of this package with the requirements
in draft-ietf-megaco-reqs-06.txt.

I'm especially referring to the following text:
"This encompasses the support of dial-in access to the NAS, but not the
contact to a AAA server for authentication, authorisation etc and the
possible subsequent set-up of a layer 2 tunnel to a remote NAS. Those are
autonomous functions of a NAS and therefore out of scope for the Megaco
protocol (see e.g. IETF RFC 2661 (L2TP) and RFC 1661 (PPP)). "

It is certainly desirable to allow legacy NAS equipment to continue
operating as currently deployed and implemented.  However, to restrict
future development to legacy capabilities is over-restrictive.  It is a
definite probability that megaco may be used for a host of things related
to AAA and tunneling (among other things) at least based on information
received from the SCN (e.g., Called Party Number, Calling Party Number,
Bearer Capability, etc.).

It is clear that the NAS package is pretty rudimentary and will have to be
extended substantially for proper operation of a Dial POP.  This may not
happen until after the white paper is released or after H.248 is approved.

If you don't want the currently defined NAS package to provide these
features, then don't include them.  But don't say they are outside the
scope of megaco.

Actually, the more I think of the current megaco architecture since the
March Compromis (reminds me of the Missouri Compromise) the more I think
the best way to support NAS behavior is via a NAS termination.  In this
case, the DS0 termination would control behaviour of the DS0 and the NAS
termination would control the behaviour of the NAS (modem type, HDLC
controller, which AAA server to use, which L2TP destination to use,
etc.).  This would have to be rolled up into a package defining the media
descriptor, eventdescriptor and signaldescriptor parameters.

Other items:

In Section 3.14.2.1.4 (CallBack Request), you take into account only AAA
initiated callback.  There are various other types of callback allowed
(e.g., PPP callback) that may not involve AAA.

In addition, there is no parameter defined for sending the number in the
Notify message.  I'd expect the encoding to be something like this:

MEGACO/1.0 [124.124.124.222]:55555
      Transaction = 5551 {
           Context = - {
                Notify = nas/1/3{
                     ObservedEvents =2222 {
                          19990729T22000000:nas/cbr{
                               ced=9195551212,
                               cing=7035551212
                          }
                     }
                }
           }
      }

where ced is Called Party Number and cing is Calling Party Number.

Disconnect events.  I didn't see any disconnect events like PPP LCP
Termination received, Loss of Carrier, etc.

Authorisation Succeed/Fail:
RADIUS doesn't separate Authentication and Authorisation.  However, they
are separate events.  Therefore, a user could conceivably pass
Authentication and fail Authorization for a service.  If these types of
indications are to be sent to the MGC, then they should be separated into
separate events.  I see that the package has the Authorisation event
defined but there is no Authentication event defined.

Chip

> > Phone and FAX: +1 613 736 0961

--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 6 Oct 1999 15:55:37 -0700

>in draft-ietf-megaco-reqs-06.txt.

As I've said on many an occasion, the requirements as written go outside
the scope of MEGACO. We even had a conference call on this issue which I
though solved the problems. Bottom line, we do not do AAA with MEGACO!!

>Bearer Capability, etc.).

If you think the current scheme is "legacy" and should be improved, you
should be contributing to the discussions going on in the AAA WG. I don't
think characterizing the method currently used by 50,000,000-odd Internet
users is overly restrictive. The Internet would not have scaled as
massively and quickly had that been true.

>features, then don't include them.  But don't say they are outside the

I think that protocols that are handled by other WG's are outside the scope
of MEGACO. The L2TP WG handles L2TP. The AAA WG handles AAA.

>(e.g., PPP callback) that may not involve AAA.

PPP callback is a part of PPP and has nothing to do with MEGACO except that
the PPP engine on the NAS will request a call setup to the MEGACO engine.
The same works for any method of setting up a call on a NAS.

>defined but there is no Authentication event defined.

If the MGC needs to know about Auth failure, it can learn that from the AAA
server out of band of MEGACO.

---

From: Chip Sharp <[email-masked]>
Date: Thu, 7 Oct 1999 08:00:24 -0400

>though solved the problems. Bottom line, we do not do AAA with MEGACO!!

As has beed discussed many times on the list, the requirements don't go
outside the scope of MEGACO.  Bottom line, I'm not talking about doing
AAA.  I'm talking about programming the MG to support NAS calls based on
call information.  This isn't AAA.

>massively and quickly had that been true.

It is true that dialin access has scaled pretty well using RADIUS.  It is
also true and has been repeated over and over again by the people who
invented RADIUS (Livingston) that RADIUS was not intended for
configuration.  Using a AAA server to configure the NAS based on calling
and called party information is a hack.  It has worked well, but it still
is a hack on the protocol and is not AAA.

I'm not proposing that we disallow the current way of doing things.  I am
saying that the MGC should be able to program the MG based on the Call
information.  This is *not* AAA.

>I think that protocols that are handled by other WG's are outside the
>scope of MEGACO. The L2TP WG handles L2TP. The AAA WG handles AAA.

I am not talking about the MGC doing AAA or doing L2TP.  I'm talking about
the MGC programming the termination to support AAA or L2TP just like it
programs the DS0 termination to do G.711 and just like it sends the remote
IP address for the RTP stream.  This doesn't mean the MGC does RTP or does
G.711.

>PPP callback is a part of PPP and has nothing to do with MEGACO except
>that the PPP engine on the NAS will request a call setup to the MEGACO
>engine. The same works for any method of setting up a call on a NAS.

That is what I'm saying.  The basic package text says the callback is only
used for AAA-based callback.  It should be allowed for all types of callback.

>If the MGC needs to know about Auth failure, it can learn that from the
>AAA server out of band of MEGACO.

I assume you mean both Authentication and Authorization.  When the call
fails due to the user failing Authentication or Authorization, the NAS must
notify the MGC of the event so the MGC can tear down the call.  The error
code in the  message (or the event descriptor) should give a reason for the
failure.

Chip