Subject: RE: [Sipping] SIP Gateway Controller

From: [email-masked]
Date: Wed, 4 Sep 2002 14:25:35 -0400

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" <[email-masked]> on 09/04/2002 02:04:42 PM

To:   "[email-masked]'" <[email-masked]>, "Yadavalli, Satyamurthy"
       <[email-masked]>
cc:   "[email-masked]'" <[email-masked]>
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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 9:10 AM
> To: Yadavalli, Satyamurthy
> Cc: [email-masked]'; [email-masked]'
> 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" <[email-masked]>@ietf.org on
> 09/03/2002
> 02:08:54 PM
>
> Sent by:  [email-masked]
>
>
> To:   "[email-masked]'" <[email-masked]>
> cc:   "[email-masked]'" <[email-masked]>
> 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: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, September 03, 2002 11:12 AM
> > To: Yadavalli, Satyamurthy
> > Subject: Re: [Sipping] SIP Gateway Controller
> >
> >
> >
> >
> > Why not use Megaco?
> >
> >
> >
> >
> >
> > "Yadavalli, Satyamurthy" <[email-masked]>@ietf.org on
> > 09/03/2002
> > 09:59:10 AM
> >
> > Sent by:  [email-masked]
> >
> >
> > To:   "[email-masked]'" <[email-masked]>
> > 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 [email-masked] for questions on current sip
> > Use [email-masked] 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 [email-masked] for questions on current sip
> Use [email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Bobby Sardana <[email-masked]>
Date: Wed, 04 Sep 2002 22:52:15 -0700

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.
[email-masked]