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

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 31 Aug 2001 13:48:21 -0400

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 31 Aug 2001 14:08:21 -0400

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

> 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.
 
> > something pretty fundamental in the world view that lead to this 
> > draft.
> > 
> > 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:
> > 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.
> > 
> > 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: Henry Sinnreich <[email-masked]>
Date: Fri, 31 Aug 2001 16:01:28 -0500

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

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Rosen, Brian
> Sent: Friday, August 31, 2001 12:48 PM
> draft-chang-sipping-bicc-network-0 0.txt
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>