Subject: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

From: Chip Sharp <[email-masked]>
Date: Thu, 01 Feb 2001 17:44:10 -0500

At 02:07 PM 2/1/2001, [email-masked] wrote:

>It doesn't really matter which version of ITU-T ISUP we reference - 
>because after 1992 they are all backwards compatible with each other.
>
>The point was that there only needs to be a single 'base' value for 
>post-1992 ITU-T ISUPs. As soon as the ISUP processor sees this, it knows 
>that it can handle unrecognised information according to the compatibility 
>procedure and so can sucessfully process the message.
>
>Given this, ISUP 1992 was chosen because it was the first version with the 
>compatibility mechanism. It would be arbitrary to choose another version - 
>why not 1997 or 2004 ??
>
>The intent of this 'base' value is to imply that the encapsulated 
>signalling is based on an ITU-T ISUP version 1992 or later, so it covers 
>ISUP 2000.
...snip...

A few questions on this:

1)  Does this cover BICC (Q.1901)?
2) Does it cover forward compatibility?
3) The current bases cover ITU, USA, ETSI and Japan.  What about the rest 
of the world?
4) What about countries that use TUP or some other non-ISUP, SS7 signaling 
(e.g., NUP)?

I don't really think everything needs to be defined today, but what is the 
extension procedure when a new base needs to be defined?  Or is it just 
hacked into a new version registered in IANA.  For examle:
         Content-Type: application/ISUP; version=q1901;
                          base=itu-t92+

I guess after all, base is optional so I'm not sure it matters if it is 
done this way.

-------------------------------------------------------------------
Chip Sharp                       Consulting Engineering
Cisco Systems
-------------------------------------------------------------------

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: [email-masked]
Date: Thu, 1 Feb 2001 16:20:47 -0700

I would argue that the 'base' parameter exists pretty much to cater to the
compatibility mechanism present in ITU-T 92 (which is in essence a forward
compatibility mechanism from the perspective of that issue). If other ISUP
variants unrelated to itu92 have independent compatibility mechanisms, then
this is perhaps something we should consider, but I don't think the authors
of the draft are aware of any. As you point out, 'base' is optional - I
believe that outside of strongly ITU-grounded networks, it will not see
substantial use.

And is it just me, or is the idea that BICC will be encapsulated in SIP
somewhat counterintuitive? Are there any services today that require that?
Anyway, if there is interest I'd be inclined to say that BICC should have
it's own MIME type which should be discussed on its own merits.

Jon Peterson
Level(3) Communications

-----Original Message-----
From: Chip Sharp [mailto:[email-masked]]
Sent: Thursday, February 01, 2001 3:44 PM
To: [email-masked]
Subject: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

...snip...

A few questions on this:

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 2 Feb 2001 09:28:21 -0500

> it's own MIME type which should be discussed on its own merits.

So, SIP-T is used for, among other things, ISUP-SIP-ISUP.
You don't think anyone wants to do BICC-SIP-BICC when SIP is one operator's
network, and the BICCs are two other operators?

I also see BICC-SIP-ISUP and of course ISUP-BICC-SIP-ISUP and variations.

Brian

---

From: "Mark Watson" <[email-masked]>
Date: Mon, 19 Feb 2001 14:47:34 -0000

Indeed. But to answer the original question, there is no requirement to
encapsulate BICC in SIP - this does not make sense.

BICC consists of two logical parts, (i) ISUP messages (which support the
narrowband ISDN/PSTN service set) and (ii) Bearer Information (which
controls the setup of the bearer connection across the ATM/IP network).

SIP-T consists of three logical parts, (i) ISUP messages (ii) Bearer
Information (in the form of SDP) and (iii) SIP headers (supporting
integration with native SIP networks.

Therefore SIP-T is already a superset of BICC. Encapsulating BICC inside
SIP-T would just result in duplicating the Bearer Information. So, in the
BICC-SIP-BICC case, the SIP messages will look just like the ISUP-SIP-ISUP
ones. When you subtract the bearer information from a BICC message, you are
essentially left with an ISUP one.

In fact, for IP networks, BICC just about uses SDP to carry the Bearer
Information, so it should interwork to SIP without *too* much difficulty
(but don't quote me on that).

Regards,

Mark

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: 13 February 2001 09:35
> Subject: Re: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs
> 
> 
> 
> Not to forget the cases where we encapsulate everything in morse code
> and smoke signals - after all, SIP is newer than those 
> methods, so... :)
> 
> Christer Holmberg
> Ericsson Finlande
> 
> Jonathan Rosenberg wrote:
> > 
> > 
> > 
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Friday, February 02, 2001 9:28 AM
> > > To: [email-masked]'; [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs
> > >
> > >
> > Seems prejudicial in favor of SIP catering to BICC. If we 
> do this, what
> > about:
> > 
> > SIP-BICC-SIP
> > 
> > I think we should request the BICC guys to be able to 
> encapsulate SIP
> > messages. After all, what about service transparency across 
> my SIP network!
> > All these operators that are deploying SIP are doing so, in 
> part, because of
> > the service possibilities. Shall I be forced to lose those 
> capabilities when
> > I traverse an IP based BICC network? Why do the BICC guys 
> get to keep their
> > services, and the SIP guys don't? After all, BICC is even 
> newer than SIP.
> > 
> > Of course, once we do that, the more fun case is:
> > 
> > ISUP-SIP-BICC-SIP-ISUP
> > 
> > in which case the encapsulated SIP messages themselves contain ISUP
> > messages, both of which are encapsulated in BICC.
> > 
> > Of course, we should probably also consider the case of:
> > 
> > SIP-ISUP-SIP
> > 
> > Think about it; a SIP phone calls a PSTN number. It goes to 
> an ss7 gateway.
> > Turns out, that this number is then forwarded to another 
> number, and that
> > number is a VoIP terminal. So, it exits at another gateway, 
> and hits the
> > terminal. I suppose we should also request the ISUP guys to 
> encapsulate SIP
> > messages.
> > 
> > Now then, we should also probably consider the case of:
> > 
> > SIP-BICC-SIP-ISUP-SIP-BICC
> > 
> > -Jonathan R.
> > "reducio ad absurdum"
> > ---
> > Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 19 Feb 2001 10:07:37 -0500

It's all in the definitions.
 
If I have two BICC systems, with a SIP system in the middle, I have several
simple goals
    1.  I want the call to proceed (that is, I want it to work)
    2.  In support of #1, I want the BICC messages the enter the SIP system
to be preserved across
            the sip message stream (which, btw, would include the new
message BICC introduces,
            and the new IE that BICC introduces)
    3. Also in support of #1, I want the bearer to work.  Here I have two
choices, depending on
            how I build my network.  I could have gateways between the BICC
networks and the
            SIP networks.  In this case, there are 3 bearer segments, and
thus the SIP network
            bearer is from the entry GW to the exit GW.  This would be the
case if there were
            a bearer change (ATM to IP for example).  In these cases, the
bearer descriptions
            change across the network boundaries.
 
            I could also have one big IP network, in which case the SIP
network has to just carry
            the SDP from the originating network to the terminating network
(and allow traffic
            in case of firewalls and NAT devices).
 
So, what does that mean to the drafts?
 
One is that the SIP-ISUP interwork document has to include the BICC messages
and IEs
that are not in base ISUP
 
Another is that we need a document describing how the bearers work in the
two cases 
above.  
 
The ISUP MIME type doesn't change, and the INFO method doesn't change.
 
Brian

-----Original Message-----
From: Mark Watson [mailto:[email-masked]]
Sent: Monday, February 19, 2001 9:48 AM
To: [email-masked]
Subject: RE: [SIP] Re: SIP digest, Vol 1 #750 - 4 msgs

Regards, 

Mark 

> From: Christer Holmberg [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > > From: Rosen, Brian [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> > http://www.cs.columbia.edu/~jdrosen
<http://www.cs.columbia.edu/~jdrosen>          PHONE: (973) 952-5000 
> > http://www.dynamicsoft.com <http://www.dynamicsoft.com>  
> >

---

From: "Mark Watson" <[email-masked]>
Date: Tue, 20 Feb 2001 14:07:51 -0000

Chip,

> Except "just about uses" isn't the same as "uses". 

I know - I chose my words carefully :-)

> Instead 
> of using SIP or 
> SDP (or even H.323), SG11 has invented a new protocol by adding 
> request/response semantics into the SDP "a = " line and 
> calling it the "IP 
> Bearer Control Protocol."

Oh yes. This is because SG11 believe in 'call/bearer separation' i.e. that
the setup of the bearer should be an autonomous process between Media
Gateways which operates independently of the Call Control layer. Kludging
SDP to do this, is, IMO, preferable to inventing something completely new or
using H.245.

In SIP, the semantics of the carried SDP are implicit in the messaging
carrying the SDP.

> This in addition to modifying H.248/Megaco to fit into their 
> "architecture."

Indeed. We (Nortel) have been trying to prevent this, but there are those
within SG11 who insist that the interface being addressed is fundamentally
different from H.248/Megaco. Personally I am not convinced by this - the
deviations from H.248 are more to do with starting out with an ATM-specific
overall solution in BICC CS1. Broadly, H.248/Megaco can functionally do
everything which the new Q.1950 can do, though there are some generic
packages defined in Q.1950 which have wider application.

To achieve the SG11 architectural aims with standard H.248 would mean basing
transport of all bearer information in BICC on SDP - which is not how BICC
CS1 works. But anyway...

> > > From: Christer Holmberg 
> [<mailto:[email-masked]>mailto:christer.hol
> [email-masked]] 
> >
> > > > > From: Rosen, Brian 
> > [<mailto:[email-masked]>mailto:[email-masked]]
> > > > > > Anyway, if there is interest I'd be inclined to say 
> that BICC
> > > > > > should have
> <http://www.cs.columbia.edu/~jdrosen>http://www.cs.columbia.ed
u/~jdrosen 
> PHONE: (973) 952-5000
> > > <http://www.dynamicsoft.com>http://www.dynamicsoft.com
> > >