Subject: [Sipping] Some comments on draft-chang-sipping-bicc-network-00.txt

From: "David R. Oran" <[email-masked]>
Date: Fri, 31 Aug 2001 13:20:55 -0400

I had a lot of trouble with the assumptions underlying this draft.

Here are some queries, which may just show that I don't understand
something pretty fundamental in the world view that lead to this draft.

- The draft uses the term "SIP network". I have no idea what such a
thing is or might be. Nowhere in any IETF RFCs or drafts is there the
concept of a "SIP network". There are only UAs, servers, and proxies.

- The draft assumes that administrative boundaries are enforced via
B2BUAs, with a protocol (undefined - is this BICC?) between them (c.f.
figure 1). Why is this needed, when there can be an administrative
boundary between any two SIP entities (UA->proxy, proxy->proxy,
proxy->server, etc.).

- Step one uses terms not used in SIP. There are no "Called ID, Calling
ID" so it isn't clear what you are doing here.

- Step 2 in your flow says "Translated address is obtained from Location
Server. This step provides the routing information in the network of
Service Provider A.". I don't think this is true, at least in any of the
addressing schemes I've seen (tel:, enum, Sip:, etc.). Location servers
do not in general do translation; they provide routes, and it isn't at
all clear that routes are confined "in the network of service provider
a". In the case of TRIP, the route could very easily point to another
service provider.

- Step 3: Why is it necessary to go to an MGC? Why can't this just be a
proxy?

- Step 4: Presumes a LOT of magic. It also presumes that there is a
separate information flow (other than standard SIP) to add this
information. Why?

Then when you finally get the end of this model flow, you say
"Encapsulating the BICC information in SIP messages has the following 
Advantages", but you never justified using BICC in the first place, let
along said anything about what things BICC has (that SIP doesn't) that
might be useful. From my cursory reading of the BICC specs, BICC solves
two problems:
A) separation of bearer specification and call/session control
B) rationalization of ISUP features
SIP doesn't have problem 1 in the first place because it uses SDP for
"bearer control". SIP doesn't have problem 2 either, because it doesn't
have non-interoperable variants that need interworking magic like ISUP.
So I don't get how BICC helps anything for SIP users.

Getting on to the claimed advantages:

Advantage 1): why is this only an advantage at the "Edge" of a network.
If it's useful I would think it would be useful end-to-end.

Advantage 2): why is an enhanced ISUP helpful here at all? If ISUP has
limitations that's ISUP's problem. It would be much more helpful if you
would say what the limitations of SIP are that require the features of
BICC.

Advantage 3): Nowhere in your flow or information model does BICC appear
except at the boundary between two "SIP networks" (to use your term).
Why then, would you carry it transparently anywhere? I suspect you're
actually thinking of a completely different scenario, where some PSTN
edge device already is doing BICC and you need to somehow transparently
get BICC across an IP cloud that doesn't support it. But that's not what
you showed...

I stopped reading carefully at this point, because clearly I don't
understand why anybody would do this unless you had BICC somewhere and
you needed to get it across a SIP cloud, as we do with ISUP and QSIG.

One last question. Why can't we just do SIP-T, with BICC as a
transparent MIME type instead of ISUP? Why do we need a whole new and
different approach?

Dave.

_______________________________________________
Sipping mailing list  http://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