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

From: Vikram Nair <[email-masked]>
Date: Wed, 23 Mar 2005 20:34:24 +0530

Hello,

Please find my viewpoint along with example scenarios embedded in the
mail below.

tx
- Vikram

Adam Roach <[email-masked]> wrote on 03/23/2005 05:12:50 AM:

> Vikram Nair wrote:
> 
> >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.
> >  
> >
> 
> 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.
> 
> >2) Making Presence information available to Presence Gateways (using
> >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.
> 
> >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.
> >  
> >
> 
> 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.
> 

If we look into the model of transporting TCAP and SCCP messages in
SIP messages, it is also on the same lines as ISUP and QSIG model is.
Here it is important to understand that, IN/AIN should not be looked
as a framework limited to providing events/triggers pertaining to a
call. There is lot more to it, in terms of call related signaling.
There are triggers/events and messages which also roughly means the
same as the SIP message, in which they would get carried. See some of
the examples below.

>
> There are no SIP messages which mean "the offhook trigger has been 
> activated." 
>

If we take the example of AIN - Termination_Attempt trigger. It would
get fired when the terminating leg gets established in the AIN switch.
This is point in call where the call has to be offered to a
destination subscriber. In case of SIP subscriber, INVITE would be
sent.

Alternatively, if we look at one possible applications of RFC 3265. An
IN/AIN event package used with SUBS/NFY SIP messages is one way of
notifying "the offhook trigger has been activated". Also, a mapping of
3XX, 4XX responses (in response to NFY) would interwork response to
IN/AIN triggers in PSTN.

>
> There is simply no way to map IN triggers to equivalent SIP 
> messages because the equivalent semantics don't exist in SIP.
> 

Below are few examples which shows possible mapping of IN/AIN triggers
to SIP messages and also, IN/AIN call related signaling messages to
SIP messages. These example assumes a network scenario with an IN
capable SSP in PSTN domain, an IN/AIN-SIP gateway also acting as SIP
proxy and a SIP UA. There can be any number of SIP proxies in path
which MAY or MAY NOT understand SCCP/TCAP MIME.

Example 1: SIPUA at some point in time, decides to initiate a call. It
sends out INVITE to a SIP proxy (which is also a AIN-SIP gateway). The
SIP proxy on receiving INVITE would initiate Create_Call (AIN message)
towards an IN capable SSP. This SSP, switches the call to final
destination. Here if we look, Create_Call message of AIN is analogous
to IAM in ISUP and INVITE in SIP.

Example 2: An IN capable SSP detects a terminating leg trigger for a
subscriber (which happens to be in SIP domain). SSP formulates
Termination_Attempt AIN trigger and sends it to SIP proxy (AIN-SIP
gateway). The SIP proxy sends out an INVITE towards SIP UA.

Example 3: Continuing from example 2, SIP UA may not responds back or
chooses to redirect the call using 3XX, in such scenario SIP proxy
(AIN-SIP gateway) may send Disconnect (AIN message) or redirect the
call by sending Forward_Call (AIN message) to the SSP respectively.

>From above examples and many such capabilities in IN/AIN it is evident
that, IN/AIN triggers/events and messages maps to SIP both at message
level and from call signaling view point. Bringing in RFC 3265 with
IN/AIN event package, a SIP proxy or SIP UA can exercise more control
on the ongoing SIP sessions while interworking with IN capable SSP.

Hope the forum agrees.

Going ahead, with present SIP framework (including RFC 3265) there
could be two approaches to interwork with IN capable SSPs - (a) to
define an IN/AIN event package (b) tunnel SCCP or TCAP as MIME.

There has been an attempt for approach (a) above, to define IN/AIN
event package, but such attempts lack completeness in most of the
aspects because of complex nature of PSTN signaling.

Here comes the benefits of approach (b) which can be used in
conjunction with approach (a) or all by itself to help realize some
services. This removes duplication of efforts, in terms of
re-inventing the wheel again i.e. defining new package which signifies
same service aspect to network nodes which IN/AIN signaling does.
However, implementation may choose approach (a) where bare minimal
parameter level interworking is sufficient enough to realize a
service.

> /a

_______________________________________________
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: Wed, 23 Mar 2005 11:19:10 -0500

Vikram,

I believe, you give the real solution to PSTN/SIP service interworking
issue: in SIP domain, call/session related information is communicated with
SIP protocol. 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.

I also have to say that I disagree with both of the approaches you list
below as a) and b). For a), there is no need to define such an event
package. You already have enough information with SIP call setup signaling
and with Dialog package. What you need to do is:

  SCP                                            Proxy, SIP UA etc..
 +----------+          +----------+             +----------+
 | Service  |          |  Service |             | Service  |
 | Provider +----------+  Gateway +-------------+ Requester|
 |          | INAP,    |          |   SIP       |          |
 +----------+  AIN,    +----------+  (basic     +----------+
               CAP etc..          call setup messages,
                                  Dialog Package etc..)

If you need a mapping between SIP domain events -messages, notifications
etc..- and IN/AIN events, you do it in service gateway -actually you also
mention about such mapping in your message so it is a suprise to me that you
think SIP entities need to know about SCCP/TCAP- . 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.

If you want to embed service gateway functionality togeher with SIP
functionality in a device, that is fine, but has nothing to do with protocol
design and does not require carrying SCCP/TCAP etc. in SIP domain.

Similar arguments hold also for approach b).

   Tolga

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Vikram Nair
> Sent: Wednesday, March 23, 2005 10:04 AM
> To: [email-masked]
> Subject: Re: [Sipping] MIME media types for SCCP and TCAP Objects
>
>
> Hello,
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 23 Mar 2005 10:39:10 -0600

>define an IN/AIN event package (b) tunnel SCCP or TCAP as MIME.

Or (c) put SCCP on some other, more appropriate IP transport (see RFC 
3332) and use *that* to communicate between your SIP node and the SS7 
network.

>re-inventing the wheel again...
>

I subscribe to the "don't reinvent the wheel" argument -- and 
apparently, more strongly than you do. Which is why I keep pointing out 
that THIS WORK HAS ALREADY BEEN DONE, and has been published as RFC 3332.

There seems to be some disconnect here. The only thing I can figure is 
that people are having a hard time *finding* the RFC. Try this link:

   http://www.ietf.org/rfc/rfc3332.txt

/a

---

From: "Banibrata Dutta" <[email-masked]>
Date: Thu, 24 Mar 2005 11:30:01 +0530

Hi,

I would like to add 2 observations here --

1) Inspite of the fact that MGCP/SGCP/Megaco existed, ppl. still went ahead
with Media-Server Control Markup embedded in SIP (few variants of it too).
At that time also similar discussions had happened as to why reinvent the
wheel ? Two things that came up few times were:-
  a) The ability to have just one signalling & media-control protocol stack,
which was especially important if the end-device was limited in resources,
s.t. another protocol stack is best avoided to save on resources.
  b) Extensibility that XML based info. transfer brought about. Frankly,
Megaco (and to some lesser extent MGCP) do have Extensibility too.
So fact is that today we do have implementations using SIP + MS Control
markup.

2) In the scenarios being discussed, --
  a) I don't see a particularly resource-limited node anywhere ?
Softswitches, Gateways, Service Control platform, are generally quite rich
in resources available to them.
  b) Talking about the Signalling protocols from the SIGTRAN farm, i.s.
M3UA, SUA etc., they are quite flexible in addressing future extensions.
They are tested, proven and stable specifications.

Are there any other major drivers for having SCCP embedded in SIP ? One
thing (seemingly trivial though) that comes to my mind are that there are no
well-supported and actively-developed M3UA / SUA open-source
implementations, w.a. there's lot of activity in SIP, i.e. if that matters
to anyone.

my 2 cents,
Banibrata.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: Wednesday, March 23, 2005 10:09 PM
> To: Vikram Nair
> Cc: [email-masked]
> 3332) and use *that* to communicate between your SIP node and 
> the SS7 network.
> 
> apparently, more strongly than you do. Which is why I keep 
> pointing out that THIS WORK HAS ALREADY BEEN DONE, and has 
> been published as RFC 3332.
> 
> There seems to be some disconnect here. The only thing I can 
> figure is that people are having a hard time *finding* the 
> RFC. Try this link:
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Mar 2005 01:19:16 -0600

Thanks. I believe your observations are largely accurate, and can be 
concisely summarized as:

   1. People have historically imagined inappropriate applications of
      SIP, and some have even deployed them.

   2. While questionable technical arguments have been offered for these
      abuses of SIP in the past, none of them even apply to the
      currently proposed extension.

I'll add my own observation that, *even* *when* people went out and used 
SIP in new and architecturally inadvisable ways -- such as media gateway 
control -- no working group within the IETF took on any work to document 
such usages. As much as possible, we try to avoid specifying Really Bad 
Ideas in standards track documents.

/a