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

From: Vikram Nair <[email-masked]>
Date: Tue, 22 Mar 2005 11:46:35 +0530

Hello,

There is another point of view here. 

The very fact of making such information available at one of the SIP
nodes, opens up limitless opportunities for applications like:

1) Offering IN services hosted in PSTN world to SIP subscribers.
SPIRITS framework currently addresses only few such IN triggers and
messages but not all.

2) Making Presence information available to Presence Gateways (using
SIP) by transporting MAP mobility management messages

Most of the time, unavailability/incomplete inter working standards
for such scenarios holds back some of the ideas.

Likewise ISUP and QSIG MIME, It would be good idea to consider
TCAP/SCCP MIMEs as an alternate mechanism for realizing
services/applications in SIP domain where inter working with SS7 is
required.

tx
- Vikram

Message: 3
Date: Mon, 21 Mar 2005 09:17:03 -0500
From: "Tolga Asveren" <[email-masked]>
Subject: RE: [Sipping] MIME media types for SCCP and TCAP Objects
To: <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

A comment related with the concept rather than with the draft itself:
I think, using SIP as transport to carry SCCP/TCAP is not a good idea. IMHO,
it is abuse of SIP and in addition to that makes the concepts/constructs of
PSTN domain visible to SIP domain entities.

 Tolga

_______________________________________________
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: Tue, 22 Mar 2005 08:37:11 -0500

I respectfully -but strongly- disagree with your opinions. For providing
PSTN based IN services, one does not need to make SIP entities
SCCP/TCAP/INAP/CAP etc. aware. Here the situation is a bit different than
carrying ISUP -actually I also do not like that approach-, because you not
only carry some non-native signaling by using SIP as transport but you also
want to use that signaling in SIP domain, i.e. you expect SIP entities to
know about its messages/concepts etc.

All of the things you list below -and alike- could be provided by
introducing a node with gateway functionality -name it whatever you want,
based on the gateway functionality it needs to provide- between PSTN and SIP
domains.

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Vikram Nair
> Sent: Tuesday, March 22, 2005 1:17 AM
> To: [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Mar 2005 17:42:50 -0600

>SPIRITS framework currently addresses only few such IN triggers and

Without expounding on the reasons that I thought (and still think) the 
entire SPIRITS architecture was not a particularly appropriate 
application of SIP, I would suggest that what you are proposing is an 
extension to the work they have done there. In my opinion, the work you 
are doing would be more appropriate to bring to that working group than 
SIPPING.

>SIP) by transporting MAP mobility management messages

That's been done. There are interoperable commercial products already 
deployed to do these kinds of things based on RFC 3332.

>services/applications in SIP domain where inter working with SS7 is

The work done to transport ISUP and QSIG in SIP is a completely 
different model. 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.

There are no SIP messages which mean "the offhook trigger has been 
activated." There is simply no way to map IN triggers to equivalent SIP 
messages because the equivalent semantics don't exist in SIP.

/a

---

From: "Seamus Gilchrist" <[email-masked]>
Date: Tue, 22 Mar 2005 18:59:27 -0500

Adam,

SS7 provides more than the support of the classical telco model IN (AIN).
SCCP/TCAP and application layers such as GSM MAP provide support for text
messaging (SMS), and a variety of database lookups. It seems that there
would be possible applications for SIP entities to want to access some of
this type of non-call-related data.

Regards,

Seamus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Tuesday, March 22, 2005 6:43 PM
To: Vikram Nair
Cc: [email-masked]
Subject: Re: [Sipping] MIME media types for SCCP and TCAP Objects

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 22 Mar 2005 18:07:39 -0600

>this type of non-call-related data.

I'll point out *again* that this was the motivation behind RFC 3332.

/a

---

From: "Tolga Asveren" <[email-masked]>
Date: Wed, 23 Mar 2005 08:33:39 -0500

One very important sentence from RFC3261:
"SIP is not a vertically integrated communications system".

If certain information is available for some device in their role as SIP
entity, than SIP is the way to communciate this information. If some
information/concept is known to such device because it has also a different
role, then the communication method of that role needs to be utilized.

For example for database lookups, why was there AIN/TCAP etc.. and we didn't
use ISUP?

   Tolga

> Behalf Of Seamus Gilchrist
> Sent: Tuesday, March 22, 2005 6:59 PM
> To: 'Adam Roach'; 'Vikram Nair'
> Cc: [email-masked]