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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 19 Nov 2003 19:01:00 -0000

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

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 19 Nov 2003 14:38:57 -0500

With all due respect, the reason I didn't ask to have it considered was I
knew that it would never be accepted, so why waste my breath.  My purpose
was to solve a problem that needs addressing.

It cannot be ignored that SIP is making major inroads into the big carriers
and dealing with ISUP and TCAP in a complete way within the context of SIP
is something that needs to happen.  Now, if INFO as transport for XML isn't
palatable, whatever.

Let me be very plain, RFC 3398 is not sufficient.  It lacks support for ISUP
maintenance commands and access to SCPs via TCAP.  These are functions that
are required by vendors and carriers integrating SIP with the existing PSTN.

I happen to be associated with one of the vendors addressing these needs at
the implementation level.  If the protocol does not serve all my needs, I
will extend it.  If you as protocol specifiers don't like the way I extend
it then put something else in place that I can use.

Hoping to be constructive,
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
Drage, Keith (Keith)
Sent: Wednesday, November 19, 2003 2:01 PM
To: 'McCandless, Kevin'
Cc: [email-masked]
Subject: RE: [Sipping] RE: [Sip] Sip support for TCAP queries

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

---

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

Let me ask: why do you need support for ISUP maintenance messages?  Are 
you using SIP to control circuits?

---

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

Please see below fpor some questions/comments....
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Frank W. Miller
> Sent: Wednesday, November 19, 2003 2:39 PM
> To: 'Drage, Keith (Keith)'
> Cc: [email-masked]
[TOLGA]Why do you need those maintanence messages? Your voice trunks
terminate at the gateway and it is the gateway, which is interested in them,
and which receives them via ISUP. Why do you need to propogate them to a
pure SIP entity in the network? Why should they care about management of
circuits, which are physically terminated at the gateway?
And again for SCP access, if one wants to speak TCAP to them, one needs
TCAP(over SCCP or over a SIGTRAN protocol like M3UA/SUA etc...). If SCP
understands it -or if one introduces a TCAP gateway for it-, one also might
use something (HTML, SOAP, XML-RPC etc...) over HTTP. I believe, the point
is, SIP is not a transport protocol.