Subject: Re: [Sipping] MIME media types for SCCP and TCAP Objects

From: Vikram Nair <[email-masked]>
Date: Thu, 24 Mar 2005 22:01:03 +0530

Hello, to all the respected list members.

There had been few discussion over past couple of days on this topic.
I would like to sumarize those and get some more valuable inputs.

1) List is yet to get an answers as to how ISUP/QSIG model is
different from the SCCP/TCAP model. There was a genuine comment in the
list that

	"These efforts centered around transporting ISUP 
	 and QSIG messages in SIP messages that mean 
	 roughly the same thing as the messages they 
	 carry -- which means that existing user agents 
	 who don't know ISUP or QSIG will "do the right 
	 thing" upon receipt of such messages"

The same holds true for SCCP/TCAP messages as explained in the
previous post  citing some examples. Like call signaling messages in
ISUP, similar call signaling messages in IN/AIN.

Are we saying that people when working for ISUP/QSIG MIMEs were unable
to locate the http://www.ietf.org/rfc/rfc3332.txt ?

We should look here that the question is not about protocol selection
towards PSTN domain. Rather analyzing the need to communicate such
info. between SIP nodes in SIP network where rfc3332 might not make
sense.

2) Suggestion:

	"If you need to interwork with a PSTN entity 
	 -e.g. SCP-, you just have a GW functionality 
	 at the boundary and that is it. There is 
	 definitly no need to expose IN/AIN concepts 
	to SIP domain."

Agreed. The GW will do interworking. But what about parameters which
does not find place holder in SIP. And still a deployment needs to
travel the last mile in SIP domain with such a useful information.

3) Suggestion:

	"IMHO, if there is an event in IN/AIN domain, which
	 does not have an equivalent in SIP domain -and if 
	 there is really a need for it-, SIP domain signaling
	 needs to be enhanced -for example extending dialog 
	 package-, rather than requiring SIP domain entities 
	 to know about PSTN concepts/messages/protocols."

This is the reason of having SCCP/TCAP MIME as an alternate to,
waiting for a new extension when everyone knows how to interpret
"Carrier" or "AlternateCarrier" (AIN prameters) and go ahead and
deploy the solution.

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: "Tolga Asveren" <[email-masked]>
Date: Thu, 24 Mar 2005 15:12:19 -0500

Vikram,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Vikram Nair
> Sent: Thursday, March 24, 2005 11:31 AM
> To: [email-masked]
> Subject: Re: [Sipping] MIME media types for SCCP and TCAP Objects
>
>
[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.
> to locate the http://www.ietf.org/rfc/rfc3332.txt ?
[TOLGA]I would think, for pure IP offloading scenarios, BICC migt be a good
alternative but people probably choose SIP, because they want to be
future-safe, i.e. they don;t want to replace much in the core network, when
SIP UAs become more popular.
> "Carrier" or "AlternateCarrier" (AIN prameters) and go ahead and
[TOLGA]IMO, the approach should be:
1- First try to understand -independent of PSTN concepts- how to implement
the reqested service purely in SIP domain -consistent with SIP architecture,
which foresees intelligent endpoints-.
2- If there is information, which needs to be convesyed by UA, Proxy,
Application Server etc.., and which can't be carried with some SIP message
currently, extend the protocol.
3- Now, you know how to provide that service in SIP domain, interworking
with PSTN is trivial with a gateway.

IMO the approach shouldn't be:
1- Impose PSTN concepts/architecture in SIP domain
2- Try a parameter-to-parameter mapping rather than a mapping on service
level

BTW, people usually use HTTP as transport in IP domain, why insisting on
SIP, in case there is a need to carry some information? (I am not proposing
HTTP to carry SCCP/TCAP :-) )

---

From: "Seamus Gilchrist" <[email-masked]>
Date: Thu, 24 Mar 2005 17:03:51 -0500

Tolga,

>1- Impose PSTN concepts/architecture in SIP domain

I don't think adding the SCCP/TCSP MIME capability as Vikram proposes 
"imposes" the PSTN architecture in the SIP domain.

Seamus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tolga Asveren
Sent: Thursday, March 24, 2005 3:12 PM
To: [email-masked]
Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects

Vikram,

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 24 Mar 2005 17:39:44 -0500

Vikram,

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-.

OTOH, SCCP/TCAP is pure signaling, no media is associated with it, just ship
it with M3UA/SUA/M2PA -of course, only if your goal is to offload SCCP/TCAP
traffic through IP-

   Tolga