Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP

From: "Schroeder, Tim" <[email-masked]>
Date: Tue, 23 May 2000 16:24:30 -0500

Mark Watson [mailto:[email-masked]] writes:

 If we have CS(A) --bicc ---CS(B)---sip --- CS(C)---bicc---CS(D) 

where 'CS' is 'Call Server', for want of a better term, then there are two
cases: 

(i) with the bearer path routed directly between Gateways controlled by
CS(A) and CS(D), and 

(ii) with further 'packet-to-packet' gateways contolled by CS(B) and CS(C)
i.e. there are three 'domains' which are physically interworked at both the
call and bearer layer.

There is some doubt as to whether (i) will be possible at all - this depends
on how the support of IP in BICC is defined over the next few months. If it
is possible, I think that it should involve maping the bearer control
mechanism in BICC to the equivalent in SIP (SDP) so that the call can still
work if it terminates on a pure SIP agent. 

Agreed.

If you do this mapping, then you've removed from the BICC information
everything which makes it BICC and not ISUP, so you're not carrying BICC
inside SIP at all. 

But just because you map the information from BICC into SIP, doesn't mean
it's removed from the BICC message, does it?  In the ISUP--SIP--ISUP case,
the ISUP information that makes sense to map to SIP (to provide the desired
level of interworking) is mapped, but the ISUP message is still passed along
in the body to allow for ISUP transparency, in case the call ends up back on
an ISUP-signaled network.  I'd think the same mechanism would apply to the
BICC--SIP--BICC case: map the BICC information that makes sense to SIP (and
the bearer stuff to SDP), but pass along the original BICC message in the
body.  Then if the call terminates in the SIP-signaled network, you've got
your interworking (to the level that you coherently mapped the BICC
information to SIP/SDP), and if the call is routed through a gateway back to
a BICC-signaled network you can still have "BICC transparency".

In case (ii), the three domains are completely independent from each other
when it comes to setup of the bearer connection. Again, the only information
from BICC left to carry over the SIP domain is the ISUP part. 

I think I'd still want to send the whole BICC message, even if the non-ISUP
part will never be used.  The gateways provide the interworking
functionality between BICC and SIP; there's no need to have them also
interwork between BICC and ISUP (even if that's relatively easy) just so I
can avoid an application/BICC or application/Q.1901 MIME type. 

If we were to carry the BICC APM parameter, which contains the Bearer
related information, over SIP, we would be inventing a new way of carrying
out bearer setup on a SIP call - an alternative to SDP. I do not think we
should do this as it would be non-backwards-compatible. 

In your case (i), interwork the bearer related information to SDP (which
will get used if the call terminates in the SIP-signaled network, ignoring
the BICC-embedded APM parameter) and leave it in the BICC message as well,
passing the whole BICC message along in the body (which will get used if the
call is routed back to the BICC-signaled network).  

In your case (ii), the gateways are going to have to piece together the
three media streams end-to-end, a first BICC APM parameter will describe the
CS(A)--CS(B) segment, SDP will describe the CS(B)--CS(C) segment, and a
second BICC APM parameter will describe the CS(C)--CS(D) segment.  I don't
think there's much BICC/APM-to-SDP interworking that can be done there, but
the BICC message may as well be passed along, rather than first converting
it to the ISUP format.

Tim Schroeder 
[email-masked] 
SBC Technology Resources, 9505 Arboretum Blvd., Austin, TX  78759 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Holland, Peter Michael (Peter)" <[email-masked]>
Date: Wed, 24 May 2000 17:23:32 +0100

Considering Tim Schroeder's response to Mark Watson's mail, it was
a little difficult to distinguish between the original, and the response,
but

> can avoid an application/BICC or application/Q.1901 MIME type. 
....

> the BICC message may as well be passed along, rather than first converting
The way the BICC will support IP bearers has not yet been finalised, but
this
case (ii) is setting up the bearers leg-by-leg, as in BICC CS1. The
following
should thus be applicable:  The information in a BICC APP parameter is of 2
types:
1. that which relates to this bearer segment.
2. that which relates to the codec negotiation procedure.

The first of these is not relevant on a subsequent leg of the call
and should not be passed on as it is likely to cause confusion on a
subsequent leg.

The concern expressed refers to "converting to the ISUP format".  I'm not
sure
what the concern really is, considering that the BICC message format is the
same
as the ISUP message format, from the message type octet onwards.

    Pete  Holland  
     Lucent Technologies,  Malmesbury, UK
     email: [email-masked]
     phone:  +44 1666 832423
     fax:  +44 1666 824515

---

From: "Schroeder, Tim" <[email-masked]>
Date: Wed, 24 May 2000 17:07:10 -0500

> a little difficult to distinguish between the original, and 

I hate Outlook.  The copy in my "sent items" folder looks beautiful; what
went out and came back on the mailing list looked wretched.  Sorry.

this
following
> and should not be passed on as it is likely to cause confusion on a

I agree that the information of type 1 is not relevant.  I'm just a little
uncomfortable having the gateway on the BICC-to-SIP side edit out part of
the BICC message to keep the SIP network happy.  It may edit out part of the
BICC message for its own reasons (hiding the details of the source network?)
but it shouldn't have to do so just because the SIP network can't
encapsulate BICC, but only straight ISUP.  

I don't know of any reason why it *couldn't* edit it out, it just seems
easier to pass along the whole BICC message transparently.  The destination
BICC network can choose to use the parts it thinks are useful, and to ignore
the parts it thinks aren't.  

In the ISUP case, we send the ISUP message transparently, without editing
out the parts known (or suspected) to be useless in the destination network.
I like that model, and it seems easy enough to follow for BICC as well.  And
even if BICC looks a lot like ISUP, and after the useless information has
been removed may look exactly like ISUP, it still seems cleaner to transmit
the BICC as encapsulated BICC, and label it as such with "application/bicc"
or some such, rather than calling it ISUP. 

sure
> what the concern really is, considering that the BICC message format is
the same
> as the ISUP message format, from the message type octet onwards.

Annex E of the Q.1901 document is all about BICC-to-ISUP interworking.  The
differences don't seem substantial, but ... 

If the BICC information is stripped of its BICC-ness and encapsulated as
ISUP, will the destination end even be able to tell that it used to be BICC?
Could that ever be useful?

Tim Schroeder
[email-masked]

---

From: "Holland, Peter Michael (Peter)" <[email-masked]>
Date: Thu, 25 May 2000 11:30:21 +0100

Tim,

> the parts it thinks aren't.  
The normal BICC processing at the receiving side of the BICC-to-SIP gateway
will process and remove the type 1 information, because it is inherently
link-by-link according to the BICC procedures.

> or some such, rather than calling it ISUP. 
I do not disagree with this in principle, but I do see a problem with how to
indicate this with the Content-Type as currently in
draft-ietf-sip-isup-mime-01.
Considering that:
1. a SIP-to-ISUP gateway ought to be able to handle a mime'd message that
originated from a previous BICC call segment, without being upgraded to
understand a new "BICC" Content-Type. (so it should be "application/ISUP")
2. there will be regional and national variants of BICC, just as there are
of ISUP.
(so the version, and base parameters are still needed as defined.)

The only reason I can see why a SIP-to-BICC gateway would be interested that
a previous leg was BICC is if there is some Type 2 information included. It
can
easily detect that by looking in the message, so maybe this is a sufficient
way of detecting this case.
If this is not considered sufficient then an additional parameter should be 
added to the Content-Type - "BICC=y/n"

> differences don't seem substantial, but ... 
The differences are not substantial.

    Pete  Holland

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 25 May 2000 13:19:54 +0100

Tim,

If we followed your proposal, then there would be no way for CS(C) to
distibguish between case (i) and case (ii). In both cases, CS(C) would
receive a SIP INVITE message containing a BICC IAM (itself containing Bearer
Control information) and also Bearer COntrol information within the SDP.

In case (i), the BICC APM information will relate to the MG controlled by
CS(A) (MG(A)), as will the SDP.

In case (ii), the BICC APM information will related to MG(A) and the SDP
will relate to MG(B).

The only sensible behaviour for CS(C) is to use the SDP in both cases, so
the BICC information will never be used, even in the BICC -- SIP -- BICC
case.

The BICC APM is essentially 'link by link' between Call Servers. It is
required that CS(B) can interpret this information and so implicitly it has
the capability to remove it, turning the BICC message back into an ISUP one.

It will be easier to come to a clear conclusion on this one when we have a
better idea of how BICC will support IP. One option being discussed is that
BICC will support carriage of SDP information, which will be 'tunnelled'
transparently from one MG, via the Call Servers, to the next MG. This
information would be rather easy to interwork to SIP.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Schroeder, Tim [mailto:[email-masked]]
Sent: 23 May 2000 22:25
To: [email-masked]
Subject: RE: [SIP] Carrying Q.BICC as an Mime-type in SIP

Agreed.

Tim Schroeder 
[email-masked]