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

From: [email-masked]
Date: Wed, 19 Nov 2003 11:13:26 EST

In a message dated 11/19/2003 10:03:49 AM Eastern Standard Time, 
[email-masked] writes:

> [TOLGA] I fail to see the reason for statement "SIP needs a formal
> methodology for obtaining TCAP query." Why? SIP is the protocol to
> create/modify sessions. And to do the query, one uses another protocol, TCAP
> or something else. Especially if TCAP is going to be used, IMO there is no
> need to discuss this in SIP/SIPPING list, it just is a different protocol.
> Also for SS7 case, ISUP is used for call control and TCAP for queries. With
> the same logic, one should be asking ISUP to be enhanced to support queries.
> 

I agree completely. SIP and TCAP are two completely separate things.

Besides, I could not see the original point that an endpoint (someone's 
telephone) needs to initiate TCAP queries. I don't think that anyone operating the 
entity at the other end of such a TCAP query would ever agree to such a thing.

Mike Pierce

---

From: "McCandless, Kevin" <[email-masked]>
Date: Wed, 19 Nov 2003 12:23:10 -0800

So, CNAM, LNP, and other SS7 data is relevant to working SIP networks that interconnect with the PSTN.  There is no standard document to define how the SIP protocol obtains the database information.  Each vendor is implementing their own way of doing this with SIP on one side during the Invite message and on the other side launching an SS7 query either with M3UA or standard SS7 TDM links.  VoIP carriers want access to the data so would it not be helpful to have a standard way of implementing this interworking.  This has already done for ISUP.  SS7 is not going away and the interworking between VoIP and PSTN can only help the VoIP initiatives.

> -----Original Message-----
> From: Frank W. Miller [mailto:[email-masked]] 
> Sent: Wednesday, November 19, 2003 1:39 PM
> To: 'Drage, Keith (Keith)'
> Cc: [email-masked]
> Subject: RE: [Sipping] RE: [Sip] Sip support for TCAP queries
> 
> 
> 
> 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
> 
> 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
> 

_______________________________________________
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: "Chong, Koan S, ALABS" <[email-masked]>
Date: Wed, 19 Nov 2003 19:42:52 -0600

I understand James Yu's ID on using the redirect server to interwork with number translation services like LNP and ITFDB. And I have communicated to him on our support/need for and our dependency on his draft to be incorporated into the new RFC of tel url.

	My earlier question is more specific. I am interested to know if there is any industry standard solution for interworking with CNAM. Is CNAM a trivial number translation that can be treated with redirect response like LNP or ITFDB?

	Another specific question is about interworking with the CLASS Auto-Recall & Callback.

	If existing solution for specific services is not available, are we looking for a general problem statement and a more universal solution? I agree that TCAP over SIGTRAN will solve this type of problem to interwork with TCAP-based PSTN services. Is this the recommended solution taken by SIPPING & SIGTRAN?

Koan
AT&T

... whether a cat is black or white so long as it catches mice. And super cat is not needed if only a couple mice need to be caught....

> Sent: Wednesday, November 19, 2003 5:39 PM
> To: 'McCandless, Kevin'; 'Drage, Keith (Keith)'
> Cc: [email-masked]; 'Frank W. Miller'
> Relevant - yes, by all means. But in order for these 
> functions to work for
> VoIP solutions of which SIP is only a part, there is no 
> requirement for the
> SIP protocol itself to obtain this sort of database 
> information. There are
> obviously alternatives (one being something like ENUM, 
> another being some
> sort of web services architecture).
> 
> For trivial applications like number translation (or CNAM), I 
> can understand
> why some might insist that this is a feasible thing to do 
> with SIP. As my
> colleague Mr. Shockey suggested earlier in this thread,it 
> would be perfectly
> reasonable for a SIP redirect server to act as a SIP-TCAP 
> gateway. One might
> send an INVITE with a tel URL Request-URI to the gateway and 
> receive a 3xx
> reponse with a Contact header containing the translated 
> number. In fact,
> this architecture was documented in a now-expired ID, which 
> can still be
> found here:
> 
> http://www.watersprings.org/pub/id/draft-yu-sip-np-01.txt
> 
> At the time, there was not sufficient interest in the WG to 
> push this draft
> forward. I got the sense that most people believed it was too 
> obvious to
> even require documentation. 
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > Sent: Wednesday, November 19, 2003 12:23 PM
> > Cc: [email-masked]; 'Frank W. Miller'
> > So, CNAM, LNP, and other SS7 data is relevant to working SIP 
> > networks that interconnect with the PSTN.  There is no 
> > standard document to define how the SIP protocol obtains the 
> > database information.  Each vendor is implementing their own 
> > way of doing this with SIP on one side during the Invite 
> > message and on the other side launching an SS7 query either 
> > with M3UA or standard SS7 TDM links.  VoIP carriers want 
> > access to the data so would it not be helpful to have a 
> > standard way of implementing this interworking.  This has 
> > already done for ISUP.  SS7 is not going away and the 
> > interworking between VoIP and PSTN can only help the VoIP 
> initiatives.
> > 
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > > Sipping mailing list  
> > https://www1.ietf.org/mailman/listinfo/sipping
> > > Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 20 Nov 2003 11:53:33 -0000

You seem to be assuming that the entire protocol space on the IP side is occupied by SIP. SIP is just one of a number of protocols that coexist to provide a solution to a problem.

Therefore, just because something exists in some form in SS7, does not mean that has to automatically have a SIP equivalent. IETF is very strong on smaller protocols working together to provide an end result (unfortunately SIP got out of hand). Therefore it is perfectly acceptable that elements within the scope of SIP are carried in, or mapped to, SIP, but other elements that are in the scope of some other IETF protocol are dealt with by that protocol.

Any requirement for protocol extensions in the IETF space need therefore to answer the question: "Is this the appropriate protocol to extend to carry my functionality?" That is therefore the question I would like to see input to. 

regards

Keith

> Sent: 19 November 2003 20:23
> interworking between VoIP and PSTN can only help the VoIP initiatives.
>