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

From: Young-Fu Chang <[email-masked]>
Date: Tue, 04 Sep 2001 13:15:08 -0500

"David R. Oran" wrote:
> 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]]
> > Sent: Friday, August 31, 2001 1:48 PM
> > To: 'David R. Oran'; [email-masked]
> > Subject: RE: [Sipping] Some comments on
> > draft-chang-sipping-bicc-network-00.txt
> >
> >
> > BICC is fundamentally an extension to ISUP that allows ISUP
> > to control bearers that are on IP or ATM (or Frame Relay, or
> > ...) networks. Wrt signalling, BICC is just ISUP with an
> > extra message, and an extra IE. There are some (ignorable for
> > the purposes of this discussion) procedures, and a way to
> > carry bearer descriptions in a couple of ways including SDP.
> > Interworking BICC to SIP is delta more than interworking ISUP
> > to SIP, if we were inclined to do so.  We can argue the
> > really small issue of whether a new MIME type is needed (I
> > say no), someone needs to take the ISUP-SIP mapping document
> > and make a BICC-SIP addition to it, and INFO gets used identically.
> >
> Agree

As mentioned in the draft, BICC has inherited the ISUP features
and is tailored for packet network. When looking at the SIP-T
picture, one side of the MGC is ISUP from the PSTN while the 
other side of the MGC is SIP-T. This SIP-T carries ISUP in 
the SIP message. Is the ISUP from the PSTN network same as 
the ISUP carried in the SIP ? The answer is No. When 
looking at what should be done to fit this new ISUP in the SIP, 
it turns out to be just like BICC. 

> 
> > Nothing to get worked up over.
> >
> OK. I saw what purported to be using BICC as an "über-SIP" to solve some
> nonexistent multi-carrier interpworking problem and wanted to see if I
> was in the weeds. If you're analysis is correct, then the draft is just
> very poorly thought out as opposed to proposing something fundamentally
> different from SIP-T.

Agree, it can be part of the SIP-T framework with different MIME
type or something can be identified. But the procedures and messages/IEs
should be carefully reviewed to fit the needs of packet network.
> 
> > If you were a carrier that deployed ISUP, you might deploy
> > BICC as a low risk signalling mechanism to get started with
> > voice-over-data-networks. You get to use your existing
> > signalling network, and use IP or ATM bearers. If you
> > subsequently decided to move to SIP (good idea), then you
> > might reasonably want to see how BICC and SIP interworks.  I
> > don't see much more interest in the subject than that at the
> > moment, but who knows.
> >
> Agreed.
> 
> > BTW, this draft is NOT in the ietf repository.
> >
> Hmmm... I clicked on a link in the ietf-announce message and it popped
> with up from www.ietf.org/internet-drafts/
> 
> Dave.
> 
> > Brian
> >
> > > -----Original Message-----
> > > From: David R. Oran [mailto:[email-masked]]
> > > Sent: Friday, August 31, 2001 1:21 PM
> > > To: [email-masked]
> > > Subject: [Sipping] Some comments on
> > > draft-chang-sipping-bicc-network-00.txt
> > >
> > >
> > > 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
> > >
> >
> 
> _______________________________________________
> 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

_______________________________________________
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