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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 18 Nov 2003 14:14:13 -0600

[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

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 18 Nov 2003 15:50:59 -0500

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

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

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

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

FM

Frank W. Miller, Ph.D.

Chief Technical Officer

sentitO Networks, Inc.

[email-masked]

-----Original Message-----

Thanks,

Kevin

---

From: Richard Shockey <[email-masked]>
Date: Tue, 18 Nov 2003 16:08:36 -0500

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.

>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.
>
>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]
>
>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?
>
>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, 
>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.
>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 
>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]
>
>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]
>
>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 

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

---

From: Tom Taylor <[email-masked]>
Date: Tue, 18 Nov 2003 16:11:33 -0500

Why not use HTML rather than SIP?

Frank W. Miller wrote:

> Anyway, you’re right, the format doesn’t matter at all, except for one 
> 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.
> 
>  
> 
> 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]
> 
>  
> 
> *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
> 
>  
> 
> 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 
> 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.
> 
>     *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]
> 
>      
> 
>     *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
> 
>      
> 
>      
> 
>     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?
> 
>      
> 
>         *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]
> 
>          
> 
>         *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
>