Re: [Sipping] SIP Gateway Controller

[Bobby Sardana <[e-mail]>]

However, there exists a SIN (SIP for IN) group that is defining IN service
access via SIP.
Following is the link:

http://search.ietf.org/internet-drafts/draft-gurbani-sin-02.txt

regards,

Bobby Sardana.
[e-mail]

[e-mail] wrote:

> This can open the debate as to whether the AIN is capable of providing the
> types of features that are enabled by the new technology environment. My
> own opinion is that the AIN is optimised to provide a small number of
> generalised features and would be very hard pressed with its centralised
> architecture to do any real form of personalization.
>
> Thanks
>
> Tom Gray
>
> "Yadavalli, Satyamurthy" <[e-mail]> on 09/04/2002 02:04:42 PM
>
> To:   "'[e-mail]'" <[e-mail]>, "Yadavalli, Satyamurthy"
>        <[e-mail]>
> cc:   "'[e-mail]'" <[e-mail]>
> Subject:  RE: [Sipping] SIP Gateway Controller
>
> True, one option that SIP providers may choose (for atleast some features)
> is to use existing AIN infrastructure.
> But they may not want to be limited to(by) features offered by AIN.
>
> - Satya
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, September 04, 2002 9:10 AM
> > To: Yadavalli, Satyamurthy
> > Cc: '[e-mail]'; '[e-mail]'
> > Subject: RE: [Sipping] SIP Gateway Controller
> >
> >
> >
> >
> > I've heard this sort of idea before. When I first created the
> > following
> > question I realised that it could be misinterpreted as being
> > sarcastic. it
> > is not intended that way and is a real question about
> > proposals of this
> > type. The basic architecture described below is very similar
> > to the AIN.
> > Why, if one wanted this functionality, would one not just use
> > the AIN.?
> >
> > Thanks
> >
> > Tom Gray
> >
> >
> >
> >
> >
> > "Yadavalli, Satyamurthy" <[e-mail]>@ietf.org on
> > 09/03/2002
> > 02:08:54 PM
> >
> > Sent by:  [e-mail]
> >
> >
> > To:   "'[e-mail]'" <[e-mail]>
> > cc:   "'[e-mail]'" <[e-mail]>
> > Subject:  RE: [Sipping] SIP Gateway Controller
> >
> >
> > One of the advantages of SIP providing such a capability is that
> > supplementary features (which may be implemented in several
> > ways and so are
> > NOT standardized for SIP environments) need not be
> > implemented in the User
> > Agents.
> >
> > A "SIP feature server" may implement new supplementary
> > services for the
> > endpoints without changes in the endpoint software which
> > results in easier
> > maintanance. For example basic call setup etc., may still happen in a
> > peer-peer fashion but when it comes to supplementary services
> > the "feature
> > server" may play a role.
> >
> > This is similar to H323 Annex-L which specifies a mechanism
> > to have megaco
> > embedded into H323. SIP also may still use Megaco mechanisms
> > inherently
> > with
> > a "sip wrapper" to accomplish this. But inorder to have a SIP entity
> > "support megaco" and also have the "SIP feature server" involved a
> > specification may need to be layed out.
> >
> > -satya
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]]
> > > Sent: Tuesday, September 03, 2002 11:12 AM
> > > To: Yadavalli, Satyamurthy
> > > Subject: Re: [Sipping] SIP Gateway Controller
> > >
> > >
> > >
> > >
> > > Why not use Megaco?
> > >
> > >
> > >
> > >
> > >
> > > "Yadavalli, Satyamurthy" <[e-mail]>@ietf.org on
> > > 09/03/2002
> > > 09:59:10 AM
> > >
> > > Sent by:  [e-mail]
> > >
> > >
> > > To:   "'[e-mail]'" <[e-mail]>
> > > cc:
> > > Subject:  [Sipping] SIP Gateway Controller
> > >
> > >
> > > Is there any effort at IETF to use SIP in a call agent model
> > > (instead of
> > > the
> > > peer-peer model that SIP is popular as) where the endpoints are not
> > > 'intelligent' and instead are controlled by a central
> > > controller - as in
> > > the
> > > case of MGCP/Megaco - to which all events (e.g., telephony
> > events) are
> > > reported to and the callAgent/controller instructs the
> > > endpoint to setup
> > > media sessions or play signals etc.,?
> > > Is the SIP's "third party call control (3pcc)" effort
> > > anything towards this
> > > direction?
> > > -Satya
> > >
> > > _______________________________________________
> > > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [e-mail] for questions on current sip
> > > Use [e-mail] for new developments of core SIP
> > >
> > >
> > >
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [e-mail] for questions on current sip
> > Use [e-mail] for new developments of core SIP
> >
> >
> >
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP