Subject: [Sipping] SCCP/TCAP MIMEs

From: Vikram Nair <[email-masked]>
Date: Wed, 6 Apr 2005 13:26:03 +0530

Greetings Tolga,

In your past mails you have correctly pointed out usage of ISUP/QSIG
MIMEs. But I have different opinion when these usages are said, to not
related to SCCP/TCAP MIME.

>	"[TOLGA]Conceptually there is quite some difference 
>	 between those cases. With QSIG/ISUP, you are trying 
>	 to offload a call via IP. The embedded ISUP/QSIG
>	 information is necessary to make the PSTN far-end 
>	 leg of this communciation to work properly, it is 
>	 not used by SIP UA logic. With SCCP/TCAP case, you
>	 expect the SIP device to be aware of those concepts."

SIP UAs are not expected to be mandatorily aware of SCCP/TCAP MIMEs. I
would like to use lines from one of your mails here: "existing user
agents who don't know ISUP or QSIG will do the right thing upon
receipt of such messages".

This explanation shall hold true for SCCP/TCAP as well.

Likewise QSIG/ISUP MIMEs, nothing is stopping SCCP/TCAP MIMEs to work
in a toll-by-pass deployment scenarios as well where PSTN far-end leg
needs to get the information to work properly.

>	"[TOLGA]Another significant difference worth mentioning 
>	 between ISUP and SCCP/TCAP cases is that, the former 
>	 has media associated with it, i.e. you can't simply 
>	 transport ISUP over IP with M3UA and forget about 
>	 the voice -well actually you could, but probably you 
>	 would like to offload your voice trunks too, because 
>	 they require more bandwith than signaling-."

Well, I have a different opinion here. When we say "ISUP has media
associated with it",  the more appropriate way of stating it could be,
that ISUP carries bearercapability which are of significance to
signaling nodes to make _some_ decisions.  The decisions here could be
negotiating/choosing the bearercapabilities or switching the circuit.

It would not be justified to leave SCCP/TCAP aside (when used in
context of AIN). As AIN also carries bearercapabilities which are of
significance to signaling nodes in service execution.

Also, if we consider, ConnectToResource construct in AIN, it also
draws the analogy wherein we can say that media is associated with
signaling. However, the means to associate media to a call might be
different i.e. a known device, with known bearercapabilities is
brought into a call context.

>	"[TOLGA]I would call imposing PSTN domain constructs 
>	 in SIP domain -and also to certain degree the 
>	 architecture itself-, because things like BSCM, EDP-R,
>	 PromptAndCollectInformation, TC-BEGIN, invokeId are not
>	 native to SIP."

As Mr. Seamus also pointed out, the idea behind SCCP/TCAP MIME is not
imposing PSTN constructs in SIP nor it expects SIP UA to understand
TC-BEGIN, BCSM etc. However, availability of additional information at
SIP proxy or end-node (optional to interpret), or toll-by-pass
scenario where IN-SIP-IN interworking (likewise ISUP-SIP-ISUP)
happening at gateways, could be benificial.

tx
- Vikram

_______________________________________________
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: [email-masked]
Date: Wed, 6 Apr 2005 14:31:01 +0530

Hello Vikram , 
In the ISUP encapsulation case , SIP signaling is used to negotiate and
open up media paths between gateways , ISUP encapsulation provides extra
signaling information needed to make PSTN features work. 

My understanding is , even the ISUP encapsulation should be used with
caution because 
1> You may be exposing ISUP data to SIP nodes who is not supposed to see
them. So there is a security concern.
 
2>ISUP payload may not reflect the the current call state properly , for
example consider multiple redirections occurring inside the SIP network
, when the call lands again on a PSTN gateway , the ISUP redircecting
party number parameters do not reflect the redirections happening in the
SIP network... or say the case if the CIC parameter , the SIP
network(say a B2BUA) updates the cic=parameter in the user info of the
sip uri or in the tel uri but the ISUP payload may contain a different
value for cic ,you may land up selecting a wrong carrier into the PSTN
if you use the CIC from the payload ...so on and so forth.

IMHO , ISUP payload is an interim solution , ultimately we should be
moving towards a seamless feature mapping between SIP and ISUP by
extending SIP semantics and mechanisms instead of a payload solution 

In the SCCP case , taking your ConnectToResource Example , this can be
easily implemented using a M3UA/M2PA solution wherein the SCP sends the
CTR over the M3UA interface to the SSP , The SSP understands this and
also knows that the resource in question is a SIP based audio server and
initiates a SIP session with the audio server ... IMHO you do not need a
SIP interface between your SCP and SSP in this case , as you do not need
the SIP session setup/teardown functionality between the SCP and the
SSP. 
You can control the SIP leg of the call using subsequent operations from
SCP to SSP as you can control a ISUP leg.The SSP and the SCP can
communicate using a user adaptation over an IP n/w without SIP.

SSP <-----CTR ------SCP
|
|
SIP
|
|
SIP Based Audio Server

An alternative scenario to this may be where SSP/SCP do not support
M3UA/M2PA but SIP , it's a bit difficult for me to imagine such a
situation as the SSP/SCP products will definitely be evolutions from
their PSTN predecessors and will support M3UA/M2PA as a natural
protocol. 
Even in such a case , the focus should be on extending existing SIP
mechanisms instead of a payload solution ... 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Vikram Nair
Sent: Wednesday, April 06, 2005 1:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] SCCP/TCAP MIMEs

Greetings Tolga,

tx
- Vikram

---

From: "Dhiraj Malhotra" <[email-masked]>
Date: Wed, 06 Apr 2005 15:31:40 +0530

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_msntagofline.htm 
Without minimum balance for 20 yrs!

---

From: [email-masked]
Date: Wed, 6 Apr 2005 16:23:45 +0530

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.

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