Subject: RE: [Sipping] RE: [Sip] Sip support for TCAP queries

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Nov 2003 14:50:05 -0500

Keith,

This is not to support the current suggestion but to get more clarification 
taking a long-range view of (Internet/PSTN) network(s) evolution.

Two cases in point:
1) TCAP carried registration messages for mobile systems, yet the 
equivalent is now done by SIP REGISTER method, which may eventually 
displace the former TCAP-carried methods.
2) Camp-on indications currently carried by TCAP that translate (partially) 
into SUBSCRIBE/NOTIFY.  Recall the previous request to expand SIP to carry 
some additional CCBS indications.

I see TCAP as being more like the transport protocols that underlies SIP, 
so am not sure that all of that functionality needs to survive (carried 
over) into the IP world.

The question I have is whether the stuff inside of TCAP messages evolves 
from an SS7-world application to an IETF application?

Put another way, if the TCAP and above stuff is migrated to 
TCAP/SUA/SCTP/IP, and the SS7 network as we know it today eventually fades 
away, does that make the TCAP and above stuff Internet protocols?

Mike

At 07:01 PM 11/19/2003 +0000, Drage, Keith (Keith) wrote:
>I dont see any justification here.
>
>The only sense I can make of the proposal so far is that SIP is used as a 
>means of transporting TCAP from one place to another. It is not a case the 
>protocol being used to make a SIP request, and the TCAP information 
>enhancing that request.
>
>The IETF will not extend SIP so it is just another transport protocol, 
>transaction protocol or whatever. There are other IETF defined solutions 
>in this space.
>
>So while the original author never progressed his original request, in 
>that he never asked for it to become a WG item or proposed that it should 
>go forward as an individual draft (and it died because the author failed 
>to refresh it), it would probably fail to progress (I daren't say never as 
>they will then prove me wrong), the former because the charter of the WG 
>would never be extended to cover it, and the latter at the IESG review stage.
>
>If there is any reason for progressing this, then the proponents need to 
>clearly distinguish a reason for putting it in SIP that relates to SIP as 
>a Session Initiation Protocol.
>
>regards
>
>Keith
>
>
>
> > -----Original Message-----
> > From: McCandless, Kevin [mailto:[email-masked]]
> > Sent: 19 November 2003 14:47
> > To: 'Richard Shockey'
> > Cc: [email-masked]
> > Subject: RE: [Sipping] RE: [Sip] Sip support for TCAP queries
> >
> >
> > Ignorance awakens in the dawn of reality.
> >
> > SIP needs a formal methodology for obtaining a TCAP query.
> > Whether the SS7 providers does this with their signaling
> > gateway or not is not the issue.  A formalized approach that
> > a vendor can implement is the point that is being raised.
> >
> >
> >
> > > -----Original Message-----
> > > From: Richard Shockey [mailto:[email-masked]]
> > > Sent: Tuesday, November 18, 2003 3:09 PM
> > > To: [email-masked]
> > > Subject: Re: [Sipping] RE: [Sip] Sip support for TCAP queries
> > >
> > >
> > > At 03:50 PM 11/18/2003, Frank W. Miller wrote:
> > >
> > > As the distributor of the NO TCAP buttons on generous display
> > > at IETF 59
> > > and fine trade shows nationwide , let me comment that this is
> > > one of the
> > > silliest ideas I have yet seen cross the SIPPING landscape.
> > >
> > > Why ..why on earth would you want to do this ..any query
> > > response mechanism
> > > can get you the data points necessary without the baggage
> > > TCAP puts you
> > > through.
> > >
> > > Talk to your SS7 vendor and demand better service or fire
> > > them. Get them to
> > > support SIP itself  query response mechanism. Send an INVITE
> > > expect a 302
> > > MOVE in response and encapsulate SS7 the data as part of a
> > > TEL URL in the
> > > response.
> > >
> > > This is a "bad idea" tm worthy of the big gong and hook.
> > >
> > >
> > > >
> > > >Aiieee, a cross is raised!!  ;)
> > > >
> > > >Anyway, you're right, the format doesn't matter at all,
> > > except for one
> > > >thing.  Expedience.  The essence of the argument against
> > > this type of
> > > >draft in general, i.e. one that uses INFO to carry anything,
> > > is usually
> > > >based on the fact that the content is application specific
> > > and so doesn't
> > > >fit with the base SIP protocol.  I can understand that and
> > > accept it, it
> > > >really doesn't matter to me.  I'm an implementor, not a protocol
> > > >specifier.  Unfortunately, the protocol doesn't do
> > > everything I need it to
> > > >do so I have to add stuff to fill in the holes when I take
> > > it into the
> > > >real world.  The other draft in this area
> > > draft-miller-sip-isup-annex is
> > > >another example of augmentation, the addition of ISUP
> > > maintenance commands
> > > >to the ISUP translation now RFC.  I could write/buy an SS7
> > > implementation
> > > >and template the messages and hook that into my
> > > CNAME/LNP/whatever at the
> > > >call control layer and to SCTP/UDP/whatever on the network
> > > side but why,
> > > >to keep the SIP implementation "beautiful"?  The bottom line
> > > is I'm not
> > > >going to pass the cost of the SS7 stack on to my customers
> > > if I can make a
> > > >simple addition to the SIP stuff and do exactly the same
> > > thing basically
> > > >for free.
> > > >
> > > >Now with respect to the specifics of the encoding, we can
> > > certainly talk
> > > >about anything.  That was the whole reason for publishing
> > > the work in the
> > > >IETF to begin with.  On 6.1.1.1 specifically, this is
> > simply a field
> > > >required in the QWP message.  The actual digits are
> > > specified in a string
> > > >not in BCD binary.  The Signaling
> > > Gateway/Softswitch/whatever just picks
> > > >up BCD from the Encoding field and fills in the appropriate
> > > value in the
> > > >actual TCAP binary message when the translation is done.
> > > The digits in
> > > >the ASCII string are converted similarly to BCD format in
> > > the TCAP binary
> > > >message also at that time.  The <Encoding  > field doesn't
> > > change and is
> > > >therefore a perfect candidate for being templated.  The only real
> > > >information that needs to be handled per query here is the
> > > actual number.
> > > >
> > > >FM
> > > >
> > > >
> > > >
> > > >Frank W. Miller, Ph.D.
> > > >Chief Technical Officer
> > > >sentitO Networks, Inc.
> > > >[email-masked]
> > > >
> > > >-----Original Message-----
> > > >From: Peterson, Jon [mailto:[email-masked]]
> > > >Sent: Tuesday, November 18, 2003 3:14 PM
> > > >To: 'Frank W. Miller'; 'Chong, Koan S, ALABS'
> > > >Cc: [email-masked]'; 'McCandless, Kevin'
> > > >Subject: RE: [Sip] Sip support for TCAP queries
> > > >
> > > >  [Moving this thread to SIPPING, where it belongs]
> > > >
> > > >Leaving aside the question of whether or not ENUM supports
> > > all of the
> > > >functions of TCAP, the main issue is whether or not SIP is
> > > the right sort
> > > >of protocol to handle this function. A query-response
> > protocol that
> > > >carries XML documents from a client to a server? Does SIP
> > > INFO really seem
> > > >to map onto that well? Aren't there other protocols that
> > are tooled
> > > >specifically to that purpose?
> > > >
> > > >Furthermore, is the encoding really the issue? XML vs.
> > > binary doesn't seem
> > > >that significant to me - if a SIP endpoint can template the
> > > XML format, it
> > > >could template the binary format as well. Regardless of the
> > > syntax, should
> > > >we expect SIP endpoints to understand the semantics of TCAP?
> > > Do we expect
> > > >a SIP user agent to understand and implement the concept of,
> > > say, a code
> > > >gap? That isn't "translation" in any sense that I recognize
> > > - it is closer
> > > >to saying that SIP user agents have to run a dual stack (SIP
> > > and TCAP).
> > > >Just look at the <Digits> stanza of the example in 6.1.1.1
> > > of the draft:
> > > >what sorts of SIP elements are going to understand binary
> > > coded decimal,
> > > >recognize numbering plans, and the like? If the answer is
> > > "only PSTN-SIP
> > > >gateways with that already have SS7 links and could
> > > therefore just send
> > > >TCAP queries over SS7", then I think there is a design issue here.
> > > >
> > > >Jon Peterson
> > > >NeuStar, Inc.
> > > >-----Original Message-----
> > > >From: Frank W. Miller [mailto:[email-masked]]
> > > >Sent: Tuesday, November 18, 2003 8:50 AM
> > > >To: 'Chong, Koan S, ALABS'
> > > >Cc: [email-masked]
> > > >Subject: RE: [Sip] Sip support for TCAP queries
> > > >
> > > >The main idea of this draft was to provide a capability for
> > > SIP endpoints
> > > >to do TCAP queries without having to implement the binary TCAP
> > > >protocol.  The motivation is that there are a lot of TCAP
> > > queries that
> > > >take place (800, LNP, CNAME) that are really simple and that major
> > > >carriers may not want to go and reimplement in an ENUM
> > > database in the
> > > >short term.  These carriers have spent a lot of money on
> > > their SCPs and
> > > >converting the to ENUM is non-trivial.  Now, the SCPs could
> > > be front-ended
> > > >and conversion can be automated but this draft provides an
> > > >alternative.  So, to answer the first question, the SIP
> > > endpoint formats
> > > >the correct query in the XML format specified and sends if
> > > using an INFO
> > > >to a Signaling Gateway (SG).  The SG then converts the query
> > > to binary
> > > >TCAP and dips the SCP.  The XML format can be templated in the
> > > >implementation so the effort is quite minimal on the SIP
> > > endpoint.  To
> > > >answer the second question, the draft talks about a couple
> > > of examples but
> > > >the specification encompasses the entire TCAP message set
> > so you can
> > > >format the appropriate dip for AR/C.  One caveat is that the
> > > draft is
> > > >Telcordia based.  It would need to be extended to take into
> > > account other
> > > >variants.  On the third question, <personal view> I'm a
> > believer in
> > > >translation over tunneling, tunneling just puts off work and mixes
> > > >messaging from different signaling networks
> > > unnecessarily</personal view>.
> > > >
> > > >FM
> > > >
> > > >
> > > >
> > > >Frank W. Miller, Ph.D.
> > > >Chief Technical Officer
> > > >sentitO Networks, Inc.
> > > >[email-masked]
> > > >
> > > >-----Original Message-----
> > > >From: Chong, Koan S, ALABS [mailto:[email-masked]]
> > > >Sent: Tuesday, November 18, 2003 11:27 AM
> > > >To: Frank W. Miller; McCandless, Kevin
> > > >Cc: [email-masked]
> > > >Subject: RE: [Sip] Sip support for TCAP queries
> > > >
> > > >
> > > >A couple specific questions:
> > > >
> > > >What is the recommendation on how a SIP network element can
> > > access the
> > > >callers' name databases (CNAM in US) in PSTN after the SIP
> > > element has
> > > >determined that the called parties have subscribed to Caller ID?
> > > >
> > > >How about interworking with CLASS Auto-Recall/Callback (CCBS
> > > in ITU?)
> > > >procedures?
> > > >
> > > >Assume TCAP over SIGTRAN is a bit long long term....
> > > >
> > > >Koan
> > > >Koan S.Chong
> > > >AT&T
> > > >1-732-420-4557
> > > >
> > > >-----Original Message-----
> > > >From: Frank W. Miller [mailto:[email-masked]]
> > > >Sent: Monday, November 17, 2003 6:18 PM
> > > >To: 'McCandless, Kevin'
> > > >Cc: [email-masked]
> > > >Subject: RE: [Sip] Sip support for TCAP queries
> > > >
> > > >You mean other than us implementing it?  No, I don't think
> > > so.  I think
> > > >its considered Rosemary's Baby by most...
> > > >
> > > >FM
> > > >
> > > >
> > > >Frank W. Miller, Ph.D.
> > > >Chief Technical Officer
> > > >sentitO Networks, Inc.
> > > >[email-masked]
> > > >
> > > >-----Original Message-----
> > > >From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > > >McCandless, Kevin
> > > >Sent: Monday, November 17, 2003 4:11 PM
> > > >To: [email-masked]
> > > >Subject: [Sip] Sip support for TCAP queries
> > > >
> > > >Has any progress been taken on the draft by Frank Miller on
> > > Carrying TCAP
> > > >in SIP messages?  Are there other drafts that address SIP
> > > access to SS7
> > > >database information through TCAP or another method?
> > > >
> > > >Thanks,
> > > >
> > > >Kevin
> > >
> > >
> > >  >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > Richard Shockey, Senior Manager, Strategic Technology Initiatives
> > > NeuStar Inc.
> > > 46000 Center Oak Plaza  -   Sterling, VA  20166
> > > sip:rshockey(at)iptel.org   ENUM +87810-13313-31331
> > > PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,
> > > Fax: +1 815.333.1237
> > > <mailto:richard(at)shockey.us> or
> > > <mailto:richard.shockey(at)neustar.biz>
> > >
> > <http://www.neustar.biz> ; <http://www.enum.org>
> > <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> >
> > _______________________________________________
> > Sipping mailing list  https://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  https://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  https://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  https://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: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Nov 2003 15:36:26 -0500

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Michael Hammer
> Sent: Wednesday, November 19, 2003 2:50 PM
> To: Drage, Keith (Keith)
> Cc: 'McCandless, Kevin'; [email-masked]
[TOLGA]In fact it is SCCP, which is the transport protocol for such messages
in SS7 world. TCAP is more like an asynchronous RPC mechanism (for example
similar to SOAP over HTTP), and does not have direct application semantic.
> from an SS7-world application to an IETF application?
[TOLGA]Personally I don't think so, because SIP is really a totally
different paradigm. For example, do we foresee to have a call model similar
to BCSM for SIP, which would make INAP/AIN meaningfull for SIP?
> away, does that make the TCAP and above stuff Internet protocols?
[TOLGA] Again my personal opinion, "Internet protocols" probably
yes -afterall Internet is not just SIP- , but I would think, when SS7 fades
away, there won't be need for the stuff above TCAP in the pure SIP network.
IMO, even today, they are mostly necessary just for gateways, because SS7
concepts are still present at them -they are a node in SS7 network-.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 19 Nov 2003 15:42:06 -0500

You make a good point.  Architecturally we should allow ISUP and related 
signalling to invade SIP only in ways that are easy to remove as we 
migrate away from SS7.  This means for one thing that ISUP encapsulation 
is a temporary measure, used to carry ISUP between well-defined gateway 
points rather than spread it around the network for various SIP entities 
to work on.  Similarly, transport of TCAP over SUA/SCTP/IP is for IP 
bridging between two SS7 networks or between an SS7 network and an 
interworking point -- it's not meant to be used between SIP elements.

The end goal is services.  TCAP messages get replaced by whatever 
provides equivalent services in the Internet (your point).  ISUP 
services get mapped into the equivalent SIP services.  The ISUP may 
eventually go away, but the services will remain.

Michael Hammer wrote:

> Keith,
> 
> This is not to support the current suggestion but to get more 
> clarification taking a long-range view of (Internet/PSTN) network(s) 
> evolution.
> 
> Two cases in point:
> 2) Camp-on indications currently carried by TCAP that translate 
> (partially) into SUBSCRIBE/NOTIFY.  Recall the previous request to 
> expand SIP to carry some additional CCBS indications.
> 
> I see TCAP as being more like the transport protocols that underlies 
> SIP, so am not sure that all of that functionality needs to survive 
> (carried over) into the IP world.
> 
> TCAP/SUA/SCTP/IP, and the SS7 network as we know it today eventually 
> fades away, does that make the TCAP and above stuff Internet protocols?
> 
> Mike
> 
> 
>> The only sense I can make of the proposal so far is that SIP is used 
>> as a means of transporting TCAP from one place to another. It is not a 
>> case the protocol being used to make a SIP request, and the TCAP 
>> information enhancing that request.
>>
>> transaction protocol or whatever. There are other IETF defined 
>> solutions in this space.
>>
>> that he never asked for it to become a WG item or proposed that it 
>> should go forward as an individual draft (and it died because the 
>> author failed to refresh it), it would probably fail to progress (I 
>> daren't say never as they will then prove me wrong), the former 
>> because the charter of the WG would never be extended to cover it, and 
>> the latter at the IESG review stage.
>>
>> If there is any reason for progressing this, then the proponents need 
>> to clearly distinguish a reason for putting it in SIP that relates to 
>> SIP as a Session Initiation Protocol.
>>
>> regards
>>
>> Keith
>>
>>
>>

---

From: Michael Hammer <[email-masked]>
Date: Wed, 19 Nov 2003 16:21:46 -0500

Tolga,

Your point about RPC semantic is well taken, but I was glossing over that 
to get to the heart of the matter, which is what is being carried that we 
would still care about in a SIP network.  The "call models" are different, 
so I don't expect such things to survive as they currently exist.  But, are 
there other things there needed to support end-user services that would be 
gaps in the current Internet architectural scheme.  Or put another way, 
will the SS7 network be kept around because access to SS7-based SCPs will 
still be needed because equivalent service capabilities can't be done in 
SIP?  I don't like the Frankenstein approach to building services.

Mike

At 03:36 PM 11/19/2003 -0500, Tolga Asveren wrote:
> > clarification
> > (partially)

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 19 Nov 2003 16:41:21 -0500

> Sent: Wednesday, November 19, 2003 4:22 PM
> To: Tolga Asveren
> Cc: Drage, Keith (Keith); 'McCandless, Kevin'; [email-masked]
[TOLGA]Maybe not just with SIP, but I would think with SIP + other Internet
protocols, one can implement existing PSTN services (I am not saying I am
sure, I did not go throught the whole list yet :) )  And to reuse existing
equipment during transition period(for example existing SCP database), I
would think one has to use the protocol supported by that equipment.
> > > From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> > > Michael Hammer
> > > > > Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping