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

From: "Roy, Radhika" <[email-masked]>
Date: Mon, 28 Feb 2005 12:52:15 -0500

Agreed.
 
It is a fact that a "device" can do many things (as stated below by Paul).
 
A "device" can be built to act the UA, Proxy, B2BUA, RTP-aware/dealing with media, location server, and/or many other things.
 
Based on some pre-define service logic, we can define a "device," for example, as follows:
 
1. 3rd Party Call Controller
2. Transcoder
3. Exploder
4. Media Bridge
4. Anonymizer (SIP Proxy with B2BUA to provide a lot of services transparent to users)
5. Others
 
Radhika

________________________________

From: [email-masked] on behalf of Paul Kyzivat
Sent: Mon 2/28/2005 12:06 PM
To: Gonzalo Camarillo
Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)'; 'sipping'; 'Shai Mohaban'; 'David R Oran'
Subject: Re: [Sipping] Draft: Functions of Current SBCs

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:
> 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
>
>
> Paul Kyzivat wrote:
>
>>
>>
>> Gonzalo Camarillo wrote:
>>
>>> 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.
>>
>>
>>
>> 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
>>
>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>
>

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 28 Feb 2005 20:04:34 +0200

Hi,

I actually do not think that having a definition of a device that is 
called SBC would help. Having different definitions for different types 
of SBCs would not help either, IMO.

I would rather say: "if you perform this function in this way, you are 
not a SIP compliant device. But you can perform the same function in 
this other way, and you will be compliant".

Of course, we need to explain the advantages of being compliant (e.g., 
faster service deployment and more innovations)

Gonzalo

Roy, Radhika wrote:
> A "device" can be built to act the UA, Proxy, B2BUA, RTP-aware/dealing
> with media, location server, and/or many other things.
>  
>   _____  
> Cc: 'Bob Penfield'; 'Alan Hawrylyshen'; 'Christer Holmberg (JO/LMF)';
> 'sipping'; 'Shai Mohaban'; 'David R Oran'
>>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
> 
>>I was referring to functions that may go against the SIP spec (e.g.,
> 
> SDP
> 
>>>>although the better answers would not be documented in this
> 
> document.
> 
>>>Gonzalo - the problem here is that there is no "normal behavior" for
> 
> a
> 
>>>SBC performs functions that are normal to a proxy or not is of
> 
> interest.
> 
>>>>>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]
> 
> <mailto:[email-masked]> ] On
> 
>>>>>>Behalf
>>>>>>sure it's interesting reading to many people, but at the end we
> 
> should
> 
>>>>>>Please also remember that WE, if I've understood correctly,
> 
> invited
> 
>>>>>>the
>>>>>>>From: [email-masked] [mailto:[email-masked]
> 
> <mailto:[email-masked]> ]
> 
>>>>>>>Exactly. As the draft indicates in its abstract and its
> 
> introduction,
> 
>>>>>>>the purpose of this exercise is to identify functions that cannot
> 
> be
> 
>>>>>>>perform a particular function, we do not have any problem. We do
> 
> not
> 
>>>>>>>>etc, and maybe exactly because there is such confusion it would
> 
> be
> 
>>>>>>>>worthwhile to describe why carriers are using these devices
> 
> today in
> 
>>>>>>>>general...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>that they can be carried out without breaking the SIP
> 
> architecture
> 
>>>>>>>Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> 
> 
>>>>>>Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping
> <https://www1.ietf.org/mailman/listinfo/sipping> 
> 
> <https://www1.ietf.org/mailman/listinfo/sipping> 

-- 
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

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 28 Feb 2005 13:59:20 -0500

I'd agree with that. This whole exercise indicates that the current set of
solutions we have do not handle all requirements. With the danger of
simplifying the problem too much, I am trying to enumerate some of those
below:

- Can we get around intermediaries not originating any messages on behalf of
either user endpoints. Use cases will be interesting (like network
originated call termination). If we cannot, then what is a solution which
preserves trust of the UEs.
- For intermediaries which are located on borders (like different network
address spaces where solutions like STUN/ICE may not be available, different
QoS boundaries - like Diffserv border element) SDP inspection and
manipulation may be required. Can we get around these ? If not what are the
solutions which preserve trust of UEs.
- THIG.
- Spam prevention. I think the identity verification mechanism addresses
this somewhat. What are the other things which can be done on intermediaries
so that trust is preserved.

We can add to this list if this looks remotely useful..

-Medhavi.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gonzalo
> Camarillo
> Sent: Monday, February 28, 2005 1:05 PM
> To: Roy, Radhika
> Cc: Bob Penfield; Alan Hawrylyshen; Christer Holmberg (JO/LMF); David R
Oran; Paul
> Kyzivat; sipping; Shai Mohaban