Subject: AW: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting

From: "Poetzl, Joachim" <[email-masked]>
Date: Fri, 17 Jan 2003 14:41:06 +0100

Hi,

by seeking a solution for a technical problem we should not consider philosophical approaches.

For the transport of SS7-signalling information the SIGTRAN protocols have been especially defined by the SIGTRAN
working group of the IETF. In this scenario SUA over SCTP could transport the TCAP information. For the time being PSTNs still exist and in converged scenarios we should use the same straight forward approach defined by the SIGTRAN group for each SS7 user part - why special treatment for TCAP???.

Why defining another approach when everythhing neccesary is already defined. Or are there doubts about the maturity in the SIGTRAN protocols?

You won´t need additional point codes and even the textbased TCAP-Endpoint in the IP cloud will cost some bucks.

Some questions on the proposed solution: 
-- How is adressing beeing resolved? 
-- TCAP dialoges are mainly used for call unrelated signalling, means no dialog exists. But one has to have an open SIP-Dialog before exchanging Info-Messages. How is that going to be resolved? 
-- For what kind of services this should be used? Is this solution anticipated for call completion services instead of usage of subscribe/notify?

Thanks

Joachim

-----Ursprüngliche Nachricht-----
Von: Frank W. Miller [mailto:[email-masked]]
Gesendet: Donnerstag, 16. Januar 2003 16:06
An: [email-masked]
Cc: [email-masked]
Betreff: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt :
Reposting

My apologies, I missed this one...

The difference here is that TCAP binary messages do not traverse the IP
portion of the network.  The impetus is similar to that for translating the
ISUP maintenance commands, SS7 stacks cost a lot (both $$ and point codes).
It makes more sense to implement a simple text representation that traverses
the IP portion of the network and is converted to binary TCAP at the gateway
to the SS7 cloud.  Also, from a philosophical point of view, since I believe
that SIP will supplant SS7 over the long run, limiting the need to implement
SS7 in new network elements is "a good thing".  This last point is of
course, just MHO.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Network, Inc.
[email-masked]

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 16, 2003 8:48 AM
Subject: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt : Reposting

>
>
> Reposting this mail as it did not receive a response on the list the first
> time.
>
>
>
>
>
> [email-masked] on 01/10/2003 11:13:02 AM
>
> To:   [email-masked]
> cc:    (bcc: Harsh Bhondwe/HSSBLR)
>
> Subject:  [Sipping] Comments: I-D ACTION:draft-miller-sip-tcap-00.txt
>
>
>
>
>
>
> Hi ,
>
> I have a fundamental question on the the usage of SIP for
> transporting TCAP messages.
>
> If I understand correctly the figure 1 in the draft, is
> something like the following:
>
>
> SIP Element           Signaling Gateway         SS7 Node
>
> TCAP applications                               PSTN Services
> TCAP                                            TCAP
> SIP--------IP----------SIP||SS7--------SS7------SS7
>
>
> Here a TCAP peer will be running on the SIP Element and will
> use SIP to exchange TCAP messages with peers(i.e other TCAPs)
> in the PSTN network.
>
> However, SIGTRAN protocols defined also by the SIGTRAN
> Working group of the  IETF have been especially designed
> for transporting Trunk/Access signaling over IP.
>
> So, could one not better accomplish this  by the
> following configuration using SIGTRAN?
>
>
> SIP Element                   Signaling Gateway        PSTN Node
>
> TCAP applications                                   PSTN Services
> TCAP                                                   TCAP
> SIGTRAN---------IP-------------SIGTRAN||SS7 ---SS7-----SS7
> (SUA over SCTP)                (SUA over SCTP)
>
>
> The difference of course is that in this case the SIP
> Element and the Signaling Gateway will have to (also)
> support SIGTRAN.They could continue to support SIP as well.
>
> Or am i missing something?
>
> thanks
> harsh
>
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
>

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip
_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Frank W. Miller" <[email-masked]>
Date: Fri, 17 Jan 2003 10:08:59 -0500

Thanks for the questions!

Comments inline.

> working group of the IETF. In this scenario SUA over SCTP could transport
the TCAP information. For the time being PSTNs still exist and in converged
scenarios we should use the same straight forward approach defined by the
SIGTRAN group for each SS7 user part - why special treatment for TCAP???.

We have a similar mechanism for the ISUP maintenance commands.  An early
version of that draft is on the IETF site and a major update that changes
the INFO body contents to an XML representation will be released within
days.  TCAP is not special in this regard.  IMHO, ISUP and TCAP are the best
place to do translations because the "semantic level" appears to me to be
the closest to where SIP session semantic level is.  These two works are
designed to augment the basic SIP-ISUP translation draft to include the
ability to control PSTN access trunks (e.g. PRI's and IMTs on T-1s) from the
PSTN and to do service delivery from existing PSTN elements (i.e. SCPs) to
SIP endpoints, both without having to implement SS7 protocol stacks in the
SIP elements.  The goal is make sharper the demarcation between SIP and SS7.
This is primarily a cost argument.  SS7 stacks are more expensive in the
marketplace than SIP stacks, so limiting the number of SS7 deployments saves
costs for the carriers.

> Why defining another approach when everythhing neccesary is already
defined. Or are there doubts about the maturity in the SIGTRAN protocols?

No, SIGTRAN is very mature and very useful for certain applications.  This
is just a different approach.  I see no reason why tunneling and translation
approaches cannot coexist in IETF standards.  Both have their applications.

> -- How is adressing beeing resolved?

One of the nice things about translation is that it limits addressing
problems to the mapping of addresses.  You can do about anything you want on
the SIP side as long as the mappings at the SIP UA and the GW are handled
appropriately.  Addressing is certainly an area that is ripe for discussion
in any standardization activity.

> -- TCAP dialoges are mainly used for call unrelated signalling, means no
dialog exists. But one has to have an open SIP-Dialog before exchanging
Info-Messages. How is that going to be resolved?

The element with the UA maintains a persistent session with the GW for TCAP
interactions.  I believe this is discussed in the draft.

> -- For what kind of services this should be used? Is this solution
anticipated for call completion services instead of usage of
subscribe/notify?

There are several service examples detailed in the draft.  Calling Name
Delivery is the one that leaps to mind.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Network, Inc.
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Jan 2003 22:40:07 -0500

You won't be surprised to hear me say that I think this is an entirely 
inappropriate use of SIP, whether you use the INFO method or not.

There is nothing in your usage that derives any benefit from SIP. There 
are no sessions, no calls, no nothing. You are merely using an INFO 
method as a way to send data from A to B. TCAP is closer to an RPC 
protocol than anything else, and SIP is certainly NOT an RPC protocol.

Tunneling ISUP over SIP (SIP-T) does make a lot of sense, since ISUP, 
functionally, is very close to SIP. We are therefore able to use SIP 
semantics for the exchange, and augment the flows with additional data 
(the tunneled ISUP message) that provides information of interest to 
gateways. The key to the utility of SIP-T is that its still SIP.

If you want an XML encoding of TCAP, I have no beef with that concept, 
but its not SIP. Have you considered SOAP? SOAP over HTTP seems a much 
better match.

-Jonathan R.

Frank W. Miller wrote:
>>For the transport of SS7-signalling information the SIGTRAN protocols have
> 
> been especially defined by the SIGTRAN
> 

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 26 Jan 2003 12:29:15 -0500

Thanks Jonathan for the response.

Your reaction is indeed expected.  I would make only two comments on your
response.  First, I do not agree with your unequivocal statement that TCAP
has nothing to do with a session.  There are several applications of TCAP
(CNAME and LNP come to mind) where there is clearly at least a fledgling
session in progress when TCAP is required.  Second, I've tried to get across
to other responders that there is a practical issue that is very important
here, that being cost.  Current PSTN protocol implementations are very
expensive to implement.  By this, I mean that the cost of protocol stacks
must be passed onto the end customer in some form.  I believe that this is
at least in part due to the fact that these protocols are "closed" when
compared with SIP.  The cost-effectiveness of SIP yields a desire to limit
the use of the PSTN protocol implementations in order to minimize the cost
of the equipment into which they are built.  This is why tunneling can be
problematic, it requires at least some part of these protocol stacks to be
in place on a larger base of equipment.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Network, Inc.
[email-masked]

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "Frank W. Miller" <[email-masked]>
Cc: "Poetzl, Joachim" <[email-masked]>; <[email-masked]>
Sent: Friday, January 24, 2003 10:40 PM
Subject: Re: [Sip] Re: Comments: I-D ACTION:draft-miller-sip-tcap-00.txt :
Reposting

---

From: "Adam Roach" <[email-masked]>
Date: Sun, 26 Jan 2003 13:18:35 -0600

"Frank W. Miller" <[email-masked]> writes:

> First, I do not agree with your unequivocal statement that TCAP
> session in progress when TCAP is required.

For those readers not familiar with TCAP, the above argument
is analogous to claiming something like, "There are several applications
of DNS (SIP SRV comes to mind) where there is clearly at least a
fledgling session in progress when DNS is required". CNAME and
LNP are nothing more than database dips.

Now, imagine someone using this argument as justification for
a proposal to tunnel XML formatted DNS queries over SIP.

> Second, I've tried to get across
> must be passed onto the end customer in some form.

And you've steadfastly ignored  responses pointing out
that the expensive part of PSTN protocol stacks is *not*
the syntactical decoding, but the implementation of the
necessary protocol semantics. A syntactic transformation gains
you little or nothing in terms of implementation complexity
and total cost of solution.

/a

---

From: "Frank W. Miller" <[email-masked]>
Date: Sun, 26 Jan 2003 14:53:03 -0500

WRT to sessions, while I can make at least some kind of weak argument about
TCAP.  Its clear that using a similar mechanism for ISUP maintenance
commands can be characterized exactly as Jonathan has described.  The only
reason for using SIP at all is the fact that its already there.  Its there
because its being used to establish sessions for phone calls.  ISUP and TCAP
are used in the PSTN for establishing calls/maintaining trunks and service
creation.  My view is that this underlying semantic similarity is enough to
justify the use of SIP.  I'd go even further, IMHO the acceptance of SIP as
a signaling protocol for the big carriers will not be embraced
wholeheartedly until these "corners" can be addressed.  Its clear that any
installation of SIP for signaling in the incumbents will have to
interoperate with existing SS7 signaling networks for the forseeable future
and that means all of SS7, not just call setup and teardown.
Interoperability can of course be addressed by tunneling as has been
described.  It can also be addressed by translation at the SIP/SS7 border.
This translation could be done to something other than SIP, e.g. SOAP as you
and Jonathan have mentioned, but why?  Why should I add another protocol,
with its missing functionality btw, when I can just do it all in the context
of SIP?

> and total cost of solution.

You are correct, the implemenation of the state machines associated with
these features is an expensive proposition.  However, the state machine
remains the same regardless of whether you're en/decoding a binary encoded
TCAP message or an XML encoded version of the same message in an INFO body.
The difference is I don't have to pay an SS7 vendor as many times for
licenses to SS7 stack instances.  This is a very significant cost savings.

FM

Frank W. Miller, Ph.D.
Chief Technical Officer
sentitO Network, Inc.
[email-masked]

---

From: "Adam Roach" <[email-masked]>
Date: Sun, 26 Jan 2003 14:51:23 -0600

"Frank W. Miller" <[email-masked]> writes:
> Its clear that any

The translation you are describing, though, has no benefit.
It's not like you're suggesting that the commands are translated
into something that performs analogous operations in the SIP
network; you're just suggesting that we perform syntactic
translations, slap them in a SIP INFO, and send them on
their way. There's no benefit over tunneling.

> with its missing functionality btw, when I can just do it all in the
context

I'm still trying to build a conceptual model of the netowork you have
in mind; however, based on the descriptions you give in this note,
it sounds like what you really want is probably sigtran. The goal
there, of course, was explicitly to not have any missing functionality
when carrying SS7 information over an IP network.

And I have long said that using SIP to establish sigtran sessions
would be an elegant solution to that sort of problem.

> these features is an expensive proposition.

No, not the state machines of the features -- the state machines of the
*protocols* themselves. In SIP terms, you're considering changing
out the parser and re-coding the application without taking into
consideration all the other "stuff" in between: the "stuff" that makes
the SIP spec 269 pages instead of a 10-page listing of ABNF.

> However, the state machine

It sounds to me like you're saying, "by inventing  new syntax that
no one has implemented yet, I'll be forced to develop a stack
in-house, at a substantial savings over licensing a third party stack."

With your own assertion that it's just as complicated regardless
of the syntax chosen, isn't it clear that you can develop an actual
honest-to-God TCAP stack just as cheaply in-house as you can
implement your own "TCAP-with-a-syntax-transform"?

/a

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 28 Jan 2003 17:54:28 -0800

I would actually recommend a BEEP package to carry TCAP instead.

thanks,
-rohan

On Friday, January 24, 2003, at 07:40 PM, Jonathan Rosenberg wrote:

> There is nothing in your usage that derives any benefit from SIP. 
> There are no sessions, no calls, no nothing. You are merely using an 
> INFO method as a way to send data from A to B. TCAP is closer to an 
> RPC protocol than anything else, and SIP is certainly NOT an RPC 
> protocol.
>