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

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 5 Sep 2001 15:54:31 -0400

In fact, SG 11 is doing just that.  The intended work product is as follows:
 -- requirements document for SIP-BICC interworking
 -- requirements document for SIP-ISUP interworking
 -- SIP profile for interworking with the PSTN
 -- main protocol document: interworking between SIP and BICC/ISUP
 -- annex: BICC-specific aspects of interworking with SIP/SDP
 -- annex: ISUP-specific  aspects of interworking with SIP/SDP

There are two interim meetings before the SG 11 meeting in February at which
the work is scheduled to be completed (trusting that 2543bis and a few other
things are ready by then):
 -- Sep 17-21 in Grassau, Germany
 -- Dec 3-7 in San Antonio TX

I am presenting the current SIP/SIPPING drafts on the topic at the Grassau
meeting.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, August 31, 2001 5:23 PM
To: 'Henry Sinnreich'; 'David R. Oran'; [email-masked]
Subject: RE: [Sipping] Some comments on
draft-chang-sipping-bicc-network-0 0.txt

Well SOME carriers are just plain more conservative than
others.  We can lead them to the water, but we can't
make them .... sip :)

BICC is going to get deployed.  Eventually, I predict
that it will all migrate to SIP.  As it does, we need
to interwork.  Not a big deal.  Not clear IETF should
do much, if anything; perhaps SG11 should write the
interop document based on the ISUP-SIP mapping document
and let us take a look before they publish.  

Brian

> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]]
> Sent: Friday, August 31, 2001 5:01 PM
> To: 'Rosen, Brian'; 'David R. Oran'; [email-masked]
> Subject: RE: [Sipping] Some comments on
> draft-chang-sipping-bicc-network-0 0.txt
> 
> 
> Understand now that BICC works for "IP or ATM bearers" but fail to see
> why we should worry about it, since SIP  users don't need it. 
> The whole
> point in SIP is to get away from such (BICC/ATM) 
> complexities, though it
> remains our work to keep SIP simple.
> 
> Thanks, Henry
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Rosen, Brian
> > Sent: Friday, August 31, 2001 12:48 PM
> > To: 'David R. Oran'; [email-masked]
> > Subject: RE: [Sipping] Some comments on 
> > draft-chang-sipping-bicc-network-0 0.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.  
> > 
> > Nothing to get worked up over.
> > 
> > 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.
> > 
> > BTW, this draft is NOT in the ietf repository.
> > 
> > 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
> 

_______________________________________________
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