??: [Sip] SIP B2BUA vs Proxy

"Chen Zaifeng,BISC TD DEW5(BJ)" <zaifeng.chen@BISC.SIEMENS.COM.CN> Tue, 13 May 2003 02:57 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12211 for <sip-archive@odin.ietf.org>; Mon, 12 May 2003 22:57:58 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4D2Nk123766 for sip-archive@odin.ietf.org; Mon, 12 May 2003 22:23:46 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2MhB23728; Mon, 12 May 2003 22:22:43 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4D2HEB23573 for <sip@optimus.ietf.org>; Mon, 12 May 2003 22:17:14 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12126 for <sip@ietf.org>; Mon, 12 May 2003 22:50:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPuO-0006YC-00 for sip@ietf.org; Mon, 12 May 2003 22:52:52 -0400
Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 19FPuN-0006Xa-00 for sip@ietf.org; Mon, 12 May 2003 22:52:51 -0400
X-Envelope-Sender-Is: zaifeng.chen@BISC.SIEMENS.COM.CN (at relayer david.siemens.com.cn)
Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.6/8.11.6) with ESMTP id h4D2r8412389; Tue, 13 May 2003 10:53:08 +0800 (CST)
Received: from pekw096e.cn001.siemens.net ([140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id h4D2qvA29746; Tue, 13 May 2003 10:52:58 +0800 (CST)
Received: by pekw096e.cn001.siemens.net with Internet Mail Service (5.5.2653.19) id <J5RSTD8D>; Tue, 13 May 2003 10:52:56 +0800
Message-ID: <23BCA2174A77D111A52D00A0C967A6E20420168C@HP5>
From: "Chen Zaifeng,BISC TD DEW5(BJ)" <zaifeng.chen@BISC.SIEMENS.COM.CN>
To: 'Arjun Roychowdhury' <aroychow@hns.com>
Cc: "'sip@ietf.org'" <sip@ietf.org>
Subject: ??: [Sip] SIP B2BUA vs Proxy
Date: Tue, 13 May 2003 09:52:01 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h4D2HEB23574
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit

Really appreciate your answer, dear Mr.Arjun.

So according with your description may I draw the conclusion that B2BUA is mainly used for service
control and should not substitute proxy as routing entity in a SIP network?

Thanks!

-----ԭʼÓʼþ-----
·¢¼þÈË: Arjun Roychowdhury [mailto:aroychow@hns.com]
·¢ËÍʱ¼ä: Monday, May 12, 2003 10:24 PM
ÊÕ¼þÈË: Chen Zaifeng,BISC TD DEW5(BJ)
³­ËÍ: sip-implementors@cs.columbia.edu
Ö÷Ìâ: Re: [Sip] SIP B2BUA vs Proxy


Moving to implementors..

Inline, prefixed by ARC>

1. For service support is B2BUA better than SIP proxy?

<ARC>
Depends on what kind of service. There are many that do not require 
a B2B at all and can be done by a pure proxy along with CPL, for example.
(Example of such services include hunt groups, call fwd, etc. etc.)
It also depends on the kind of capabilities you can expect from your 
participating
end points. For example, in the SIP model, services such a transfer can be 
directly
hosted on the endpoints by using REFER mechanism. However, it is possible 
in many
deployments one cannot assume intelligent endpoints nor support for REFER 
and in that case, such
services need to be done centrally.

In a nutshell, what you plan to use as the 'service manager' depends on:
        a) What is the nature of service (routing based pre-call service, 
mid-call service etc)
        b) What is the network you are deploying into (assumptions on 
'intelligence' of nodes)
        c) Scalability reqts of your network 


2. Is B2BUA suitable to be used as routing entity in the following 
SIP/SIPT network planning schemas?
    -Hiberarchy structure like PSTN, which has hiberarchied 
proxies/routing entities. Some one believe that B2BUA can be used to 
substitute call stateful proxy at the edge of such a SIP/SIPT network 
-Flat structure, which has peered routing entities but hiberarched routing 
database. In this case some  one believe that B2BUA is even more suitable 
as routing entity

<ARC> 
Again, if I just go by your requirement of the above, I dont believe a B2B 
is required only for this.
If your question is, 'Even if I need a pure proxy ,can I achieve it by a 
B2B' the answer would
be yes - but you need to decide why - by looking at the overall picture of 
your network which
you would know best. For example, does your server need to kick-in mid 
call and perform some
services which need signalling control to be performed by your server ?
If not, you can do without a B2B. Even if required, can you
assume that your network can support endpoints being REFERed to a b2b for 
mid-call services that 
require it ?
If so, you dont need to be a B2B all the time. And so on...
Also do note, a B2B has implied complexities as well, wrt e-e encryption, 
looping etc. You need to be aware of the same.

And then, do read through previous archives, where you will come across 
interesting 'hybrids'
such as 'transparent proxy' , 'B2B proxy' and so forth.

In short, many implementors have combined the functionality of a proxy and 
a B2B and actually
switch between these modes internally depending on the service required. 
Some do it by being 
a pure B2B and some do it by playing 'dialog id' tricks and switching 
between proxy and B2B (for
those who cannot afford to B2B all calls all the time). 
Needless to say, the implementors need to be aware of the perils of doing 
the same and judge 
for themselves between the devil (above mentioned hacks)  and the deep 
blue sea.. (not believing a world exists today that is not pure SIP ;-)

Id suggest you read the following:

http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-service-examples-04.txt
http://www.softarmor.com/sipping/drafts/draft-ietf-sipping-3pcc-03.txt
http://www.ietf.org/rfc/rfc2824.txt (CPL requirements)
http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-06.txt
http://www1.cs.columbia.edu/sip/talks.html (some interesting papers on 
implementing certain services
with SIP)

A lot of services and how to do them are encapsulated in the above. There 
are more
drafts for your perusal too.

So basically, you need to decide.

regds
Arjun

--
Arjun Roychowdhury @ Hughes Software Systems
11717 Exploration Lane, Germantown MD 20876
(O): 301 212 7860 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip