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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Feb 2005 16:45:16 +0200

Brian,

I agree with documenting:
1) bad behavior -- we have better answers
2) bad behavior - we need to do something

although the better answers would not be documented in this document.

Still, I would not like to document here normal behavior, for the 
reasons given before in this thread.

Thanks,

Gonzalo

Brian Rosen wrote:
> 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
> 
> 
>>-----Original Message-----
>>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
>>
>>
>>
>>>-----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
>>
> 
> 
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~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

---

From: Hans Persson <[email-masked]>
Date: Thu, 24 Feb 2005 16:14:10 +0100

>From the point of view of this list it might be sufficient to point out
that there are better answers available, but from a real-world point of
view there are often customers who are only interested in making stuff
work, without upgrading to newer clients. "This client works fine
without the firewall, so it should work fine with it as well!" They
couldn't care less if something breaks the spec, as long as it works.

Regardless of what one is developing, there'll always be legacy
equipment that has to be taken care of.

Hans

-- 
Hans Persson <[email-masked]>    Ingate - Firewalls with SIP & NAT
Ingate Systems AB  +46 13 210877   http://www.ingate.com/

Private: <[email-masked]>  http://www.lysator.liu.se/~unicorn/

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2005 10:35:15 -0500

> reasons given before in this thread.

Gonzalo - the problem here is that there is no "normal behavior" for a 
B2UA or an SBC. There are behaviors that might be "normal" for a proxy. 
But then people deploy an SBC instead of a proxy. Whether the SBC 
performs functions that are normal to a proxy or not is of interest.

It is good however if certain behavior can be described simply, by 
relating it to already defined behavior for other kinds of sip components.

	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 28 Feb 2005 18:41:40 +0200

Paul,

if your box performs one of the functions proxies perform (e.g., rewrite 
the Request-URI), you can call it an SBC, or whatever name you wish, but 
it will be a proxy and there will be nothing new to specify there.

I was referring to functions that may go against the SIP spec (e.g., SDP 
rewriting). We need to document them and come up with alternative 
solutions (e.g., session policies) that are, as people usually put it, 
"SIP friendly".

Thanks,

Gonzalo

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 28 Feb 2005 11:56:19 -0500

Gonzalo

We are all a little caught in the "deer in the headlights" phenomenon of
wishing middleboxes would go away and realizing that they aren't, and
recognizing that ignoring them makes the problem worse, not better.

We can all agree, I believe, that marketing departments will call anything
they market by any name they wish, and we can't do anything about that.

Nevertheless, I think we have to accept that there is a device called an
SBC, and, with the possible differentiation Henry notes (enterprise/consumer
vs carrier), are pretty recognizable beasts.  I think we CAN come up with a
reasonably helpful list of common functions they do.

I think such a list is useful, and that includes the functions that they do
which we would all class as "normal".  It is useful because we can then
point to that list and say "if you do these things, you are an SBC, and we
ask you to behave in a particular way", which I believe is the goal of this
work: to specify "good behaviors" for the things that SBCs do.  Good
behaviors include "normal" behaviors, and I for one think it is useful to
say what they are.  

The reason is simple: if we define the list as the function of the device,
rather than the mechanism, then we can choose the most appropriate
mechanisms and recommend them.  That will, I hope, prevent some from
choosing some other, less appropriate behavior for that function.

Brian

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Monday, February 28, 2005 11:42 AM
> To: Paul Kyzivat
> Cc: Brian Rosen; 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg
> (JO/LMF)'; 'David R Oran'; 'Shai Mohaban'; 'sipping'

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2005 12:06:19 -0500

Gonzalo,

If some incarnation of an SBC is really "just" a proxy, then I agree 
with you. But if it is in reality a B2BUA, which tries to be transparent 
and perform functions that otherwise might be done by a proxy, as well 
as a few that can't be done by a proxy, then I would like to understand 
that by having it spelled out.

For instance, hypothetically we might have a device that:
- is inserted in path via Route header
- forwards messages in both directions like a proxy
- preserves dialog info like a proxy
   (from/to tags, callid cseq)
- alters From and To URIs like a B2BUA
- alters SDP like a B2BUA
- based on altered SDP, terminates and reoriginates
   RTP media streams.

This is neither fish nor fowl. I want to know about the proxy-like 
things it does as part of the context to understanding it in full.

	Paul

Gonzalo Camarillo wrote:
>> B2UA or an SBC. There are behaviors that might be "normal" for a 
>> proxy. But then people deploy an SBC instead of a proxy. Whether the 
>> SBC performs functions that are normal to a proxy or not is of interest.
>>