Subject: RE: [Sipping] TCAP tunneling

From: "Kaitki Agarwal" <[email-masked]>
Date: Mon, 2 Feb 2004 10:59:41 -0500

Typically we use ISUP tunneling in SIP when the end exchange is talking
to another switch who is terminating traditional SS7 links to save cost
on SS7 links. The end exchange is the one who has all the subscriber
profiles and knows if it needs CNAM or LNP or AC/AR. If we have a way to
tunnel TCAP in SIP using INVITE (as suggested below) we can access all
these services from the end exchange. 
TUA is not yet RFC so I would prefer not to use it. With SUA you still
need TCAP ASN.1 BER encoded message. Instead of building Sigtran I can
use SIP if it has a TCAP extension.
It is not just space constraint , it is cost of writing/buying SIGTRAN
stack and building then supporting it in to the system. 

Thanks
Kaitki   

-----Original Message-----
From: Banibrata Dutta [mailto:[email-masked]] 
Sent: Monday, February 02, 2004 12:26 AM
To: [email-masked]; Kaitki Agarwal; [email-masked]
Subject: RE: [Sipping] TCAP tunneling

hi,

franly, i'd say that, it depends on your motivation/reason to use SIP
for 
tunneling TCAP. of course you can tunnel TCAP, but why you'd want to, is
a justification you'd have to work out. AFAIK, there's not ietf-draft
that says, how.

you can obviously tunnel TCAP query in an INVITE or INFO for that matter

(ideally in INVITE s.t. a SIP-dialog is also created which may be used
to model the TCAP dialog as well, perhaps!). the ASN.1 BER encoded TCAP
messages may then reside within the body of a multi-part (MIME) enc,
INVITE.

infact 1 reason i see where this may make sense is that you would rather
not have two stacks s.a. SIGTRAN and SIP for signalling transport, and
use SIP as the *only* signalling solution, i.e. for the signalling
application as well as for signalling transport, and support legacy/TCAP
apps by tunneling them within SIP. but then, you generally have the
constraints of
not-enough-
space, (for 2 stacks) only on resource-limited devices, s.a. hand-sets,
embedded devices etc., but i am unable see (yet), how TCAP can be
related to such devices.

my 2 cents,
Banibrata Dutta,
  Hewlett-Packard ISO (P) Ltd,
  29, Cunningham Road,
  Bangalore - 560052
  Ph: +91-80-22051796

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Monday, February 02, 2004 10:20 AM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sipping] TCAP tunneling
> 
> 
> Hi
>    TCAP is used for Transaction Capabilities i.e database
> related while SIP with ISUP tunneling is used between MGCs. 
> So I don't think TCAP can be tunneled in SIP.
> 
> Ranjit
> Ph: 8520408/16 extn: 2173
> 
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Kaitki Agarwal
> Sent: Monday, February 02, 2004 8:28 AM
> To: [email-masked]
> Subject: [Sipping] TCAP tunneling
> 
> 
> Hi
>  Can we tunnel tcap message in SIP as we do  ISUP. If not why.
>  
> Thanks
> Kaitki
> Jj~Yzy=i~Rz}y
> 
> _______________________________________________
> 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: "Banibrata Dutta" <[email-masked]>
Date: Tue, 3 Feb 2004 10:35:19 +0530

Hi Kaitki,

I see your point. Well, the idea of using standards for such
things is:
a) it's a standard, so every node you talk to speaks the same
lingo, and there are no major interworking issues with n/w
elements from other vendors.
b) you don't have to re-invent the wheel, i.e. you get a logic,
that is well understood, mature, robust and stable (i.e. all
the goodies).
c) you can probably buy it off the shelf (so a cost is attached).

The pitfalls of not using a standard, i.e. using a draft, that
*may* not become a standard are just the opposites of a),b) 
and to some extent c). I think the bigger danger is (b) i.e.
you re-invent the wheel and there are chances that it doesn't
go thru a strong and prolonged community review, and you *may*
leave few holes which you keep patching for the rest of the
life of such a product.

coming back to the point of using SIP, well, i've already said,
you definitely can use it. and i didn't realize that your 
intention was to save on the ASN.1 encoding/decoding (that you
have to do in SUA), but then ASN.1 gives you the power (and
at time compactness of "binary encoding") of representation
that is again standard and hence you get a),b) & c), which you
lose if you use something like a customized-XML message-set etc.

for your purpose SIGTRAN (w/SUA) + regular TCAP layer is the
way to go. or even more widely deployed and used - SIGTRAN (w/M3UA)
+ regular TCAP/SCCP. although less popular (i think than SIGTRAN), 
you may like to evaluate TALI (the RFC version).

my 2 cents,
regards,
Banibrata.

> From: Kaitki Agarwal [mailto:[email-masked]] 
> Sent: Monday, February 02, 2004 9:30 PM
> To: Banibrata Dutta; [email-masked]; [email-masked]
> Typically we use ISUP tunneling in SIP when the end exchange 
> is talking to another switch who is terminating traditional 
> SS7 links to save cost on SS7 links. The end exchange is the 
> one who has all the subscriber profiles and knows if it needs 
> CNAM or LNP or AC/AR. If we have a way to tunnel TCAP in SIP 
> using INVITE (as suggested below) we can access all these 
> services from the end exchange. 
> TUA is not yet RFC so I would prefer not to use it. With SUA 
> you still need TCAP ASN.1 BER encoded message. Instead of 
> building Sigtran I can use SIP if it has a TCAP extension. It 
> is not just space constraint , it is cost of writing/buying 
> SIGTRAN stack and building then supporting it in to the system. 
> 
> Thanks
> Kaitki   
> 
> franly, i'd say that, it depends on your motivation/reason to 
> use SIP for 
> tunneling TCAP. of course you can tunnel TCAP, but why you'd 
> want to, is a justification you'd have to work out. AFAIK, 
> there's not ietf-draft that says, how.
> 
> (ideally in INVITE s.t. a SIP-dialog is also created which 
> may be used to model the TCAP dialog as well, perhaps!). the 
> ASN.1 BER encoded TCAP messages may then reside within the 
> body of a multi-part (MIME) enc, INVITE.
> 
> infact 1 reason i see where this may make sense is that you 
> would rather not have two stacks s.a. SIGTRAN and SIP for 
> signalling transport, and use SIP as the *only* signalling 
> solution, i.e. for the signalling application as well as for 
> signalling transport, and support legacy/TCAP apps by 
> tunneling them within SIP. but then, you generally have the 
> constraints of
> not-enough-
> space, (for 2 stacks) only on resource-limited devices, s.a. 
> hand-sets, embedded devices etc., but i am unable see (yet), 
> how TCAP can be related to such devices.
> 
> my 2 cents,
> Banibrata Dutta,
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of 
> [email-masked]
> >    TCAP is used for Transaction Capabilities i.e database related 
> > while SIP with ISUP tunneling is used between MGCs. So I 
> don't think 
> > TCAP can be tunneled in SIP.
> > 
> > Ranjit
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > Of Kaitki 
> Agarwal