Subject: RE: [SIP] authentication at gateway

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

I understand and agree that support for a signaling protocol inside another
signaling protocol is highly undesirable.  However, SIP does not support
mid-call terminal events that I'm aware of.  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)?

Anyway, I respect that the type of functionality I've discussed within SIP
probably violates the principles of a protocol and I appreciate the
feedback.  Mid-call terminal events are outside of the scope of SIP.

Thanks,
Bert

(I apologize for changing the subject of this thread.)

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: Friday, July 07, 2000 4:19 PM
To: Culpepper, Bert; Gardell, Steve; 'Jonathan Rosenberg'; Serban Tatu
Cc: siplist
Subject: RE: [SIP] authentication at gateway

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.

There are several reasons why the service has to be agnostic of
the type of client. Such as for
1. the ease of introduction of new services and
2. any to any communications.

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

Henry

>-----Original Message-----
>From: Culpepper, Bert
>[mailto:[email-masked]]
>Sent: Wednesday, July 05, 2000 9:46 PM
>To: Henry Sinnreich; Gardell, Steve; 'Jonathan
>Rosenberg'; Serban Tatu
>Cc: siplist
>Subject: RE: [SIP] authentication at gateway
>
>
>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
>>>
>>>
>>> _______________________________________________
>>> SIP mailing list
>>> [email-masked]
>>> http://lists.bell-labs.com/mailman/listinfo/sip
>>>
>>
>>
>>_______________________________________________
>>SIP mailing list
>>[email-masked]
>>http://lists.bell-labs.com/mailman/listinfo/sip
>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

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

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 8 Jul 2000 10:05:58 -0700 (PDT)

Culpepper, Bert writes:
 > If we can transporting ISUP and

   SIP is great and all, but IP seems like a much
   more efficient transport for MGCP/MEGACO.

		  Mike

---

From: Henry Sinnreich <[email-masked]>
Date: Sat, 08 Jul 2000 17:11:37 -0500

>   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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 08 Jul 2000 23:58:14 -0400

> inside of SIP (for those who wish to support it)?

Because ISUP provides information that is very much related to the
function of SIP in the
first place - initiation of sessions between end points. There is a
natural mapping of ISUP
messages to SIP messages for this very reason - both are call
establishment protocols. If you ignore the ISUP, the SIP is still useful
and makes sense by itself. The semantics of the protocol are driven off
SIP, *not* the ISUP in the payload. That is not the case if you tunnel
megaco over SIP.

I would not advocate tunneling DHCP over SIP, HTTP over SIP, or SLP over
SIP, since those protocols 
don't do the same thing SIP does. Same with megaco/mgcp. Tunneling them
over SIP serves no purpose. SIP is not a good transfer protocol (see the
Guidelines for Authors of SIP Extensions:
http://search.ietf.org/internet-drafts/draft-rosenberg-sip-guidelines-00.txt).
Just use the native transport define by the protocol. 

I understand you have an application where you want an app server to
have access to media services provided by an MG attached through a
softswitch. Thats a fine thing to do. I also understand that this
requires megaco/MGCP to be used between the app server and the MG, going
through the softswitch in order to achieve consistency of control. Now,
just because SIP *also* runs between the softswitch and app server, does
not mean that if you also need megaco between them, you should tunnel
megaco through SIP. Just run megaco as an additional protocol between
the two.

-Jonathan R.
-- 
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