Subject: RE: [Sipping] SCCP/TCAP MIMEs

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 6 Apr 2005 11:16:16 -0400

Dhiraj,

I would concur with this.  SIP should not be used just as a transport
mechanism.  SCTP would be more appropriate.  Can you explain why this is
not simply using SIP for transport?

Mike

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>[email-masked]
>Sent: Wednesday, April 06, 2005 6:54 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: RE: [Sipping] SCCP/TCAP MIMEs
>
>Hi Dhiraj ,
>
>I was trying to point out that, in my opinion, a SIP based 
>solution is not really needed between the SCP/SSP as we seem 
>to be using SIP as just a transport mechanism in this 
>scenario. The user adaptation protocol family , M3UA/M2PA/SUA 
>were I guess were designed to do that job. SIP is more of a 
>session setup/teardown protocol, and not really meant to be 
>used as a backhaul mechanism.
>
>When you mention a SIP n/w between an SCP and and SSP like 
>node , I assume it is an IP network :) , so it may be wiser to 
>transport the TCAP information using an appropriate transport 
>like M3UA/M2PA/SUA over that network. The user adaptation 
>layers are definitely peer to peer and the network does not 
>need to understand them. You would want to use the "SIP 
>Network" , if you want to leverage the SIP NE functionalites 
>like a Proxy,Location Server etc, and to open up some kind of 
>session between the endpoints in the process. Here we do not 
>seem to have that requirement.
>
>Basically the question we need to look at is why SIP ? what 
>value addition is SIP doing in this scenario ? IMHO , SIP is 
>definitely not a protocol to do this job and there are other 
>mechanisms to do this and already standardized and implemented 
>in many products.
>
>A TCAP to SIP interworking may be needed in cases wherein we 
>want some AIN or any TCAP based service to work with a SIP 
>endpoint(note that this is not the transport scenario between 
>an SSP and an SCP or any such boxes), in that case , iff 
>required, SIP may need to be extended to convey the additional 
>feature information to the SIP endpoint. A payload solution 
>will not be ideal even in that case as we do not really want 
>our SIP entities/endpoints to be "TCAP aware" so that a 
>particular feature can work.
>
>
>Regards,
>Sayan
> 
>-----Original Message-----
>From: Dhiraj Malhotra [mailto:[email-masked]]
>Sent: Wednesday, April 06, 2005 3:32 PM
>To: Sayan Chowdhury (WT01 - TELECOM SOLUTIONS)
>Cc: [email-masked]
>Subject: RE: [Sipping] SCCP/TCAP MIMEs
>
>Hi Syan, list,
>	The discussion is going more on possible interworking 
>scenarios of AIN with SIP rather than appreciating the need to 
>address the concept.
>
>Going through the draft I feel that the intention is not 
>limited to AIN signaling. There are other driving requirements as well.
>For example, Assume that there is a SIP network between SSP 
>like node and SCP hosting services based on TCAP. In such a 
>scenario, the usage of INAP is not there and you would like to 
>send TCAP messages over SIP. In that case, I think the draft 
>is very much useful.
>
>Also, It is possible that SCP hosting TCAP based services is 
>simultaneously talking to some other SSP on TCAP/SCCP/MTP3 itself.
>Hence,
>the usage
>of M3UA may or may not be there depending upon the requirements.
>
>Regards
>Dhiraj
>
>_________________________________________________________________
>NRIs, operate Rupee Checking Account. 
>http://creative.mediaturf.net/creatives/citibankrca/rca_msntago
>fline.htm
>
>Without minimum balance for 20 yrs!
>
>
>_______________________________________________
>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: "Dhiraj Malhotra" <[email-masked]>
Date: Thu, 07 Apr 2005 09:15:59 +0530

Hi Michael,
              It is possible to have SIP network as transport when it is 
already deployed.
Adding SCTP will not be preferable when you already have some existing 
network nodes
supporting SIP.

It will be wise to capitalize the investment already done viz.a.viz an
architecturally pure solution.

Further, there are deployments which are doing TCAP-SIP interworking
though not yet standardised by ietf. It make sense to tunnel payload
in such a scenario which is analogous to SIP-T. Here most of the services
(TCAP based services) are achieved using SIP-TCAP interworking and
for some tunneling is required.

Regards
Dhiraj

>From: "Michael Hammer (mhammer)" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>
>CC: <[email-masked]>
>Date: Wed, 6 Apr 2005 11:16:16 -0400
>
>Dhiraj,
>

_________________________________________________________________
Marriages at Bharatmatriony.com 
http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Relationships that 
last forever.

---

From: David R Oran <[email-masked]>
Date: Thu, 7 Apr 2005 09:11:06 -0400

On Apr 6, 2005, at 11:45 PM, Dhiraj Malhotra wrote:

> Hi Michael,
>              It is possible to have SIP network as transport when it 
> is already deployed.
Fine, then do it over Telnet. Just about every box in the world 
supports Telnet :-)
This logic utterly escapes me. SIP is not a transport protocol.

Those who have known me for a while know that I have coined a few 
"Oran's laws of distributed systems", one of which states:
"Any application protocol which gains wide acceptance will inevitably 
be used as a transport protocol for some other application".

Examples:
	IM -> file transfer
	HTTP -> everything (including IP)
	Telnet -> network management, file transfer

> architecturally pure solution.
what you call "wisdom" I call short-sighted expediency.

> http://www.bharatmatrimony.com/cgi-bin/bmclicks1.cgi?74 Relationships 
> that last forever.
>
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "Seamus Gilchrist" <[email-masked]>
Date: Sat, 23 Apr 2005 12:14:20 -0400

On the assumption of the validity of "Oran's laws of distributed systems"
one wonders why the following example
	 SIP -> TCAP, SCCP
would stand in exception.

Cheers,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of David R Oran
Sent: Thursday, April 07, 2005 9:11 AM
To: Dhiraj Malhotra
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] SCCP/TCAP MIMEs

Examples:
	IM -> file transfer

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: "David R. Oran" <[email-masked]>
Date: Sun, 24 Apr 2005 15:45:51 -0400

> would stand in exception.
It doesn't. But inevitability is not equivalent to desirability.

David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]