Subject: RE: [Sipping] SIP Gateway Controller

From: "Yadavalli, Satyamurthy" <[email-masked]>
Date: Wed, 4 Sep 2002 17:16:12 -0400

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 4:55 PM
> To: 'Yadavalli, Satyamurthy'; 'Adam Roach'; [email-masked]'
> Cc: [email-masked]
> Subject: RE: [Sipping] SIP Gateway Controller
> 
> 
> >I proposed that an ability for SIP not to be restricted to 
> peer-to-peer
> would be useful.
> 
> This makes no sense and breakes the architecture and all its 
> advantages.

I don't know if an optional extension can cause so much damage. It may be
beyond my comprehension to understand what "breakes the architecture".
 
> >Just as the proponents of H323 
> > decided to define Annex-L
> 
> H.323 is not a role model for SIP, or we would do H.323.

Never said so. The comparison is made only because both are peer-peer models
inherently.

Thanks Rosen Brian for the answer I received from you several days ago (for
my original mail) that there is no effort to use SIP in a callagent model
and that the 3pcc effort is not intended in this direction. This is all I
wanted...neither am I proponent of H323 nor  am I a critic of SIP :-)

-Satya
 
> Henry 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Yadavalli, Satyamurthy
> > Sent: Wednesday, September 04, 2002 1:51 PM
> > To: 'Adam Roach'; [email-masked]'
> > Cc: [email-masked]'
> > Subject: RE: [Sipping] SIP Gateway Controller
> > 
> > 
> > Please see inline:
> > 
> > > -----Original Message-----
> > > From: Adam Roach [mailto:[email-masked]]
> > > Sent: Wednesday, September 04, 2002 2:36 PM
> > > To: 'Yadavalli, Satyamurthy'; [email-masked]'
> > > Cc: [email-masked]'
> > > Subject: RE: [Sipping] SIP Gateway Controller
> > > 
> > > 
> > > I'm a bit confused.
> > > 
> > > SIP is inherently peer-to-peer. Trying to force a 
> > centralized model of 
> > > control on it can only lead to spectactular failure.
> > 
> > "force"!!?
> > 
> > I proposed that an ability for SIP not to be restricted to 
> > peer-to-peer would be useful. Just as the proponents of H323 
> > decided to define Annex-L aware of the restrictions imposed 
> > by a peer-to-peer only model.
> > 
> > > I'm really trying to understand your motivation here. It's 
> > almost like 
> > > you're saying, "I really like this word 'SIP' that I keep 
> > hearing, but 
> > > I don't like anything about how the protocol to which it 
> > refers works. 
> > > Is there any work ongoing to make it act like ISDN instead?"
> > 
> > Appreciate if you closely go through my earlier mail that 
> > talks about the benefits of implementing supplementary 
> > features independently of the implementations of endpoints. I 
> > don't know from where the ISDN issue came!
> > 
> > > So, I'll restate Tom's earlier question a bit more 
> > directly: You have 
> > > already identified that Megaco operates in this model. You have 
> > > already identified that H.323 can operate in this model, 
> when used 
> > > with the Annex-L extensions. There are protocols in 
> existence that 
> > > fill the ecological niche you describe. Why are you 
> looking for yet 
> > > another one?
> > 
> > Definitely not to have a 'simple endpoint' (e.g., an IP 
> > phone) having to support H323.
> > 
> > Again, please refer to my previous mail that gave a reason 
> > why we may want SIP to "tunnel" megaco for supplementary 
> > feature support. This is definitely not defining YET another 
> > protocol nor is it "...don't like anything about... Is there 
> > any work ongoing..."
> > 
> > Hope this helps in understanding the intention of my original 
> > mail...it maynot be construed as a like or a dislike for a 
> > specific protocol.
> > 
> > -satya
> > > 
> > > /a
> > > 
> > > > -----Original Message-----
> > > > From: Yadavalli, Satyamurthy [mailto:[email-masked]]
> > > > Sent: Wednesday, September 04, 2002 13:05
> > > > To: [email-masked]'; Yadavalli, Satyamurthy
> > > > Cc: [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/listin> fo/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
> > 
> 
_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Wed, 04 Sep 2002 19:50:30 -0500

> > feature support. 

I am not sure this is a good idea. SIP endpoints should understand SIP
and must not be required to understand other telephony protocols like
SGCP, MGCP, MEGACO, H.323 and other. 

Otherwise one would have to track which endpoints understand what
tunneled protocol and devices like SIP phones, media servers, service
controllers, voice mail, etc. can understand which tunnel content. 

Please see
ftp://ftp.isi.edu/in-notes/search.ietf.org/internet-drafts/draft-ietf-si
pping-cc-framework-01.txt how these components interwork.

SIP has enough features adapted to IP communications already and is not
a transport protocol for other protocols, that are purely telephony
oriented - though SIP-T does exactly that, too bad IMHO.

Please see 

Henry

> Sent: Wednesday, September 04, 2002 4:16 PM
> To: 'Henry Sinnreich'; 'Adam Roach'; [email-masked]'
> Cc: [email-masked]; 'Rosen, Brian'
> I don't know if an optional extension can cause so much 
> damage. It may be beyond my comprehension to understand what 
> "breakes the architecture".
>  
> Never said so. The comparison is made only because both are 
> peer-peer models inherently.
> 
> Thanks Rosen Brian for the answer I received from you several 
> days ago (for my original mail) that there is no effort to 
> use SIP in a callagent model and that the 3pcc effort is not 
> intended in this direction. This is all I wanted...neither am 
> I proponent of H323 nor  am I a critic of SIP :-)
> 
> -Satya
>  
> > Henry
> > 
> > > > > True, one option that SIP providers may choose (for 
> atleast some 
> > > > > features) is to use existing AIN infrastructure.
> > > > > > following question I realised that it could be 
> misinterpreted 
> > > > > > as being sarcastic. it
> > > > > > 09/03/2002 02:08:54 PM
> > > > > > implemented in the User Agents.
> > > > > > 
> > > > > > services for the endpoints without changes in the endpoint 
> > > > > > software which results in easier
> > > > > > 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
> > > > > > > anything towards this direction?
> > > > > > > -Satya
> > > > > > >