Subject: RE: [Sipping] Draft: Functions of Current SBCs

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 23 Feb 2005 17:17:19 +0100

Hi,

I agree with Gonzalo. We can list all the functions in the world, and I'm sure it's interesting reading to many people, but at the end we should identify how and what affects SIP and SIP procedures. 

Please also remember that WE, if I've understood correctly, invited the SBC vendors to provide information about what functions the SBCs provide - NOT to argue whether they are bad or not.

There has also been a few mails about where in a network the SBCs can be located. I also think that we need to remember that there may be more than one SBC between the end-users, and that must be taken into consideration when the "toolbox" is extended... 

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 21. helmikuuta 2005 14:12
> To: Shai Mohaban
> Cc: 'Bob Penfield'; 'sipping'; 'Alan Hawrylyshen'; 'David R Oran'
> Subject: Re: [Sipping] Draft: Functions of Current SBCs
> 
> 
> Hi,
> 
> > If people think we should not include here things that can 
> potentially
> > be handled by other entities such as SIP proxies then so be it. 
> 
> Exactly. As the draft indicates in its abstract and its introduction, 
> the purpose of this exercise is to identify functions that cannot be 
> performed with the current SIP toolbox. Once we identify these 
> functions, we will extend the toolbox appropriately.
> 
> However, if a proxy, which is part of the current toolbox, 
> can already 
> perform a particular function, we do not have any problem. We do not 
> need to document what operators do with their proxy servers.
> 
> > But on the other hand you see arguments that SBCs are 
> redundant or evil,
> > etc, and maybe exactly because there is such confusion it would be
> > worthwhile to describe why carriers are using these devices today in
> > general...
> 
> The scope of this draft is clearly not to state whether or 
> not SBCs are 
> evil. We are only interested in functions that require SIP 
> extensions so 
> that they can be carried out without breaking the SIP architecture 
> (e.g., end-to-end integrity, confidentiality and feature negotiation).
> 
> Regards,
> 
> Gonzalo
> 
> 
> _______________________________________________
> 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: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Feb 2005 09:40:10 -0500

Wouldn't it actually make sense to go ahead and list all the functions,
classify them (normal behavior, bad behavior -- we have better answers,
bad behavior - we need to do something, ...) and then go work on the parts
that need attention?

I don't want to revisit this again later and have to go through that work
again.

Brian

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Christer Holmberg (JO/LMF)
> Sent: Wednesday, February 23, 2005 11:17 AM
> To: Gonzalo Camarillo (JO/LMF); Shai Mohaban
> Cc: 'Bob Penfield'; 'David R Oran'; 'Alan Hawrylyshen'; 'sipping'
> Subject: RE: [Sipping] Draft: Functions of Current SBCs
> 
> 
> Hi,
> 
> I agree with Gonzalo. We can list all the functions in the world, and I'm
> sure it's interesting reading to many people, but at the end we should
> identify how and what affects SIP and SIP procedures.
> 
> Please also remember that WE, if I've understood correctly, invited the
> SBC vendors to provide information about what functions the SBCs provide -
> NOT to argue whether they are bad or not.
> 
> There has also been a few mails about where in a network the SBCs can be
> located. I also think that we need to remember that there may be more than
> one SBC between the end-users, and that must be taken into consideration
> when the "toolbox" is extended...
> 
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
>