Subject: RE: [SIP] authentication at gateway

From: Christian Huitema <[email-masked]>
Date: Fri, 7 Jul 2000 15:10:59 -0700

> Client specific knowledge, such as MGCP inside is IMHO a very
> bad architecture.

Yep. MGCP is designed to stop at the "call agent" (or MGC, or softswitch.)
The combination of the call agent + a set of MGCP controlled gateways should
behave as one large SIP platform. It should definitely not expose its
internals to 3rd parties.

The whole problem of DTMF detection is nasty, but the rules are basically
the following: there are uses of DTMF that are essentially internal to the
call-agent+gateway combination, which can use the MGCP event/signal
mechanism. Some of these uses may be in response to signalling events, that
trigger some service inside the call agent. Using DTMF here is a local
choice; a gui based client would probably use pop up windows and menus
instead; MGCP events are the equivalent to these pop up menus.

Then, there are uses of DTMF in which DTMF is essentially a substitute to
voice recognition. The SIP controlled gateway is connected to a remote
server, that pops a set of questions. The simplest architecture there is to
carry DTMF over RTP. If the server is only interested in DTMF signals, it
can use SIP/SDP to negotiate a "tone" payload; if the server want to provide
either DTMF or voice recognition, it should use a sufficently capable voice
channel. (A problem here is that negotiating two audio channels within a
single SDP command is almost impossible.)

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Culpepper, Bert" <[email-masked]>
Date: Sat, 8 Jul 2000 11:18:06 -0500

I expect it's obvious I don't have a lot of experience discussing a topic on
this list :), sorry for merging issues (and going beyond the subject of this
thread).  I would like to comment though.

Means of authentication are provided by SIP.  And for the scenario described
in the original message, 183 is a good solution and works during session
establishment (for PSTN-based terminals specifically).

Now providing a means within SIP to access MGCP/Megaco functionality within
an UA that supports both SIP and MGCP/Megaco (a Softswitch for example) is
not too far fetched is it?  I look forward to seeing more discussion on
endpoint control by SIP-based service applications.  (I'll wait patiently
:)).

Bert

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, July 05, 2000 11:59 PM
To: Culpepper, Bert
Cc: Henry Sinnreich; Gardell, Steve; Serban Tatu; siplist
Subject: Re: [SIP] authentication at gateway

You are merging a bunch of issues here which are really separate.

I agree that each service will have its own means of authenticating
users of that service. SIP already provides three ways of obtaining
authentication for requests - http basic, http digest, and pgp. If the
service wishes to use these mechanisms to authenticate subscribers,
than
that is its decision. If the entity acting as UAC (gateway or
softswitch) cannot obtain information required to provide credentials,
then users through that gateway can't access those services. 

If an application wishes to authenticate through a media conversation,
this is also its choice. Doing so works just fine now with SIP, by
collecting DTMF or doing speech recognition or whatever, as part of
the
media stream, using 183, for example, to establish early media. This
will alleviate the gateway from the "burden" of authentication from
each
service, as requested, and do so in a manner which works for gateways,
PC clients, IP phones, or whatever, in a uniform fashion. These
mechanisms are not all that secure in reality (remember, this ain't
the
PSTN anymore), but thats also a separate issue.

It is a separate and orthogonal issue as to whether the DTMF is
carried
within SIP, and orthogonal and separate once again about whether SIP
UAs
need to speak megaco in order to be controlled by a device providing
services. I have many comments on this issue, and it is on my todo
list
to collect them and respond to the earlier thread on the subject. In
any
case most of you can guess my feelings on mandating megaco in a SIP UA
in order to access services.

-Jonathan R.

"Culpepper, Bert" wrote:
> 
> My study of gateway capabilities has not revealed an answer to
Serban's
> question other than that authentication (via the scenarios
described) is not
> available in gateways today and is not likely to show up anytime
soon if at
> all.  IMO, the most likely solution is very much like #3 for the
scenario
> given.  An MCGP or Megaco compliant gateway can collect and report
DTMF
> digits in signaling separate from the media.  However, this requires
the SIP
> UAS to also "speak" one of these protocols (obviously, not a good
solution
> at all).  In networks where PSTN phones are served there is also
likely to
> be a Gateway Controller that provides an interface between the
gateway and
> SIP UA.   A practical and feasible approach is to extend the
gateway's
> MGCP/Megaco-based event detection and reporting to SIP UAs (for
which at
> least one solution has been proposed).  The application-specific
prompts can
> be provided by the application server and leave the gateway to
performing
> its "gateway" functions.  A SIP "only" (non MGCP/Megago specific)
solution
> for PSTN-phone event detection and reporting (as has also been
proposed)
> would allow the service to be agnostic to the endpoint type but may
not map
> to MGCP and Megaco.
> 
> Maybe we'll see a solution in the near future for all terminals
(SIP, PSTN,
> others?).
> 
> Bert
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, July 05, 2000 6:02 PM
> To: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu
> Cc: siplist
> Subject: RE: [SIP] authentication at gateway
> 
> >I suggest that the appropriate
> >"converged"
> >architecture is to have authentication controlled from outside
> >the gateway and to implement it via a SIP Proxy(like?)
> >element in
> >situations where we want the core service to be
> >agnostic as to whether
> >the endpoint is a gateway or a UA.
> 
> Exactly right!
> 
> Henry
> 
> >-----Original Message-----
> >From: [email-masked]
> >[mailto:[email-masked]]On Behalf Of
> >Gardell, Steve
> >Sent: Wednesday, July 05, 2000 6:42 AM
> >To: 'Jonathan Rosenberg'; Serban Tatu
> >Cc: siplist
> >Subject: RE: [SIP] authentication at gateway
> >
> >
> >> -----Original Message-----
> >> From: Jonathan Rosenberg [mailto:[email-masked]]
> >> Sent: Wednesday, July 05, 2000 12:01 AM
> >> To: Serban Tatu
> >> Cc: siplist
> >> Subject: Re: [SIP] authentication at gateway
> >>
> >>
> >> THe most likely scenario is one you left out: the
> >prompting and
> >> collection for the PIN are all performed by the originating
> >> gateway. In
> >> general, the entity demanding authentication will
> >not know that the
> >> request is through a gateway. I believe its unlikely
> >the entity would
> >> return 200 OK, or even a 401 with content. Rather,
> >just a 401.
> >>
> >> So, upon receiving the 401, the gateway performs some local
> >> operation to
> >> get the username and password. Perhaps it plays out an
> >> announcement and
> >> collects the username/password; perhaps they are
> >simply established
> >> ahead of time and stored in a database - the gateway
> >just fetches them
> >> when prompted for authentication.
> >>
> >
> >
> >A practical issue with this approach is that gateways are often
> >deployed in support of many different services that may have
> >different authentication requirements. Placing all of the
> >authentication smarts in the gateway makes it difficult to roll
> >out new services. Now admittedly this is a "telco centric" view
> >of the service world - I suggest that the appropriate
> >"converged"
> >architecture is to have authentication controlled from outside
> >the gateway and to implement it via a SIP Proxy(like?)
> >element in
> >situations where we want the core service to be
> >agnostic as to whether
> >the endpoint is a gateway or a UA.
> >
> >
> >> -Jonathan R.
> >>
> >> Serban Tatu wrote:
> >> >
> >> > Hi,
> >> >
> >> > How is authentication performed by a SIP-enabled gateway?
> >> Let's say somebody on
> >> > a PSTN phone wants to gain access to a service and
> >> therefore has to provide a
> >> > username/password. Some scenarios come to mind
> >(<attention>newbie
> >> > here</attention>):
> >> >
> >> > Scenario 1 (smart gateway):
> >> >
> >> > - SIP UAS at service side sends a 401 unauthorized as a
> >> response to the INVITE.
> >> > The response contains a voice prompt audio file (e.g.
> >> <announcer_voice>Gimme
> >> > username/password</announcer_voice>).
> >> > - gateway is so smart that it knows how to play the prompt
> >> and collect DTMF
> >> > tones representing username and password, which it then
> >> sends back encoded
> >> > somehow to the service.
> >> >
> >> > Scenario 2 (not so smart gateway):
> >> >
> >> > - SIP UAS at service side sends back a 200 OK response to
> >> the INVITE. The
> >> > response contains the voice prompt as before.
> >> > - gateway knows how to play the audio file, sends ACK,
> >> media connections are
> >> > open.
> >> > - SIP UAS at service side then sends an INFO
> >message with a
> >> DTMF collection
> >> > scheme (voice prompt could also be sent here).
> >> > - gateway collects the tones and sends them back with
> >> another INFO message.
> >> >
> >> > Scenario 3 (dumb gateway):
> >> >
> >> > - SIP UAS at service side sends back a 200 OK response to
> >> the INVITE.
> >> > - gateway and SIP UAS establish their media channels.
> >> > - service then plays the whole authentication scenario
> >> through the media
> >> > channels. Gateway lets DTMF tones flow through the
> >media path.
> >> >
> >> > Do any of these scenarios make any sense? It seems to me
> >> that 1 and 2 are sci-fi
> >> > given the current gateway solutions, while 3 might not be
> >> possible because the
> >> > gateway grabs the DTMF tones, or if it doesn't
> >then it's an
> >> ugly solution since
> >> > signaling and media are all mixed together.
> >> >
> >> > Thanks,
> >> > Serban
> >>
> >> --
> >> Jonathan D. Rosenberg                       72 Eagle
> >Rock Ave.
> >> Chief Scientist                             First Floor
> >> dynamicsoft                                 East
> >Hanover, NJ 07936
> >> [email-masked]                     FAX:
> >(973) 952-5050
> >> http://www.cs.columbia.edu/~jdrosen         PHONE:
> >(732) 741-7244
> >> http://www.dynamicsoft.com
> >>
> >>

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Rosen, Brian" <[email-masked]>
Date: Sat, 8 Jul 2000 22:41:20 -0400

Actually, Megaco is specified over a wide variety of transports including
UDP, TCP and SCTP.  In each case, there are mechanisms to assure
"reliability",
although the definition changes somewhat depending on many factors.  SCTP
is indeed a good choice in several scenarios, which I would suspect, would
be the same kinds of situations where running SIP on SCTP would be
appropriate.

In many cases, as with sip, and MGCP, it is very appropriate to run Megaco
over UDP, and I usually suggest you start that way.

Brian

> Sent: Saturday, July 08, 2000 6:12 PM
> To: Michael Thomas; Culpepper, Bert
> Cc: Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu; siplist
> >   SIP is great and all, but IP seems like a much
> >   more efficient transport for MGCP/MEGACO.
> I understand MGCP/MEGACO needs SCTP for reliable transport
> across the net. Not that I think it is good idea, since you end
> up with a MGCP/MEGACO network under GC control instead of the
> open Internet.
> 
> Henry
> 
> >From: Michael Thomas [mailto:[email-masked]]
> >Sent: Saturday, July 08, 2000 12:06 PM
> >To: Culpepper, Bert
> >Cc: Henry Sinnreich; Gardell, Steve; 'Jonathan
> >Rosenberg'; Serban Tatu;
> >siplist
> >Culpepper, Bert writes:
> > > If we can transporting ISUP and
> > > QSIG inside of SIP why can't a subset of MGCP and
> >Megaco be transported
> > > inside of SIP (for those who wish to support it)?
> >
> >   SIP is great and all, but IP seems like a much
> >   more efficient transport for MGCP/MEGACO.
> >
> >		  Mike
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Jul 2000 09:23:14 -0700

> up with a MGCP/MEGACO network under GC control instead of the

Uh? Megaco has been toying with SCTP, but MGCP is definitely designed to run
over UDP, using timers, etc. that behave just like those in SIP. AFAIK UDP
is also an authorized transport for Megaco. OTOH, MGCP was definitely not
design as an "open Internet" or "end to end" protocol. It is a client-server
protocol, and third parties are expected to only see the gateway, which is
the client, through the call agent, which is the server. MGCP was carefully
designed to integrate well with SIP; the idea of transporting MGCP data over
SIP is nonsense.

Christian Huitema