Subject: [SPIRITS] INAP-SIP Interworking: Basic questions

From: "Hemant Agrawal" <[email-masked]>
Date: Fri, 12 Apr 2002 19:15:36 -0700

Hello,
    In my understanding, the current focus of SPIRITS group is to provide
the existing IN capabilities to
SIP network.
What about providing SIP services to existing SSPs.
or hosting IN services in SIP environment (IP )?

For the new implementations, I feel it is much easier to host services in
SIP than installing new
SCPs.  Is their any significant work being done in this direction.
Is it wise to do so?

 One instance I found of such service is the Nortel-Telia implementation in
the pre-spirits draft.
In that example, the SIP server is being used as a Redirecting Server.
However in case of providing support for mid call features, shouldn't a
stateful SIP Proxy server is required?

Thanks
Hemant

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: [email-masked]
Date: Fri, 19 Apr 2002 09:14:13 +0200

Dear Hemant,

I agree with you in you understanding regarding  the scope of SIN (SIN is just about triggering IN
services from SIP, specifically from "softswitches").

However, I am not sure to understand your proposal:

a) The part between the SIP server and "SIN" is unclear to me. This can not be easilly called SIN
node, since a "SIN" node would be a softswicth able to trigger an IN service with an INAP type of
protocol). In you picture it looks more like a SIP/INAP gateway.

b) The SSF-SIN part looks like more part of the SPIRITS architecture, where the SSF connects to a
SPIRITS proxy.

I think that if we refer to SIP services triggered from SSFs, the SPIRITS part apply, while for SS7
services from SIP, PINT applies.

By the way, in 3GPP standardisation, work is being done for triggering of IN (CAMEL to be specific)
services from SIP networks. The principles of SIN are used. The SIP node handles the session to a
node called IMS-SSF (like a SIN node) to trigger CAMEL.  Please refer to 23.278 (now in draft stage)
from www.3gpp.org.

Best regards,

Jorge Gato
Vodafone
Spain

"Hemant Agrawal" <[email-masked]>@lists.bell-labs.com con fecha 18/04/2002 21:01:18

Por favor, responda a "Hemant Agrawal" <[email-masked]>

Enviado por:   [email-masked]

Asunto:   Re: [SPIRITS] INAP-SIP Interworking: Basic questions

Hi  All,
          Thanks for all the responses!

I went thru the work of SIN design team. I am still feeling that the focus
of this team is more for providing interworking for SIP to access the IN
services not the vice versa.

I have modified the architecture diagram as in the draft.

          ************************************

          * +-------o------------+  SIP      *

          * |SIP Service Layer   |  Entity   *

          * +--------------------+           *

          ************************************

                       |

                       |  SIP *

                       |

                   +---------------+

                   |  SIN          |

                   +---o-----------+

                       |

                       +-----+ INAP

                             |

              **********|**************************

              * +-------|-------------------+     *

              * |+------o------+   SSP      |     *

              * ||  SSF        |            |     *

              * |+-------------+            |     *

              * ||  CCF        |            |     *

              * |+------o------+   SS7      |     *

              * +-------|-------------------+     *

              * ***********************************

The general idea behind this architecture is to create services using SIP as
if all communication was based on IP and all clients and servers were SIP
enabled.  And for the SSF, the SIP server will look like SCF.

This system works well in Redirecting SIP mode to support services that
execute before the end-to-end media sessions are established.  These
services include, for example:

   - call transfer and number portability for redirecting calls

   - call waiting and call offering for announcing a pending call

   - call screening and don't disturb for filtering incoming calls

   - automatic call distribution and 800-services for selecting

     termination point, etc

The SIP Redirect Server receives a SIP INVITE message for each call
regardless of which network the call is being set up in.  The SIP server
MAY apply any kind of service logic in order to decide on how to respond to
the invitation.  Service logic may interact with the user to allow the user
to specify how to handle a call.

However provider other sip services to the SSF is still a question as the
IN model may not support them.

Thanks
Hemant

----- Original Message -----
From: "Vijay K. Gurbani" <[email-masked]>
To: "Hemant Agrawal" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, April 13, 2002 7:24 PM
Subject: Re: [SPIRITS] INAP-SIP Interworking: Basic questions

> or hosting IN services in SIP environment (IP )?

Hemant:

Hosting IN services in SIP environments is covered by the IETF SIN
Design Team (SIN => SIP/IN Interworking).  We have gone through the
last call for the first I-D, which maps the IN BCSM into SIP protocol
state machine.  You can access that particular I-D at:

http://www.iit.edu/~gurbvij/I-D/draft-gurbani-sin-00.txt

I am about to submit it to the SIP/SIPPING/SPIRITS WGs as a final
form of last call.  So, if you have any comments after your review
it, please let me know.

There is also an (outdated) implementation I-D that details our
implementation experience with what is described in the sin-00.txt
I-D.  You can obtain the implementation I-D from:

http://www.iit.edu/~gurbvij/I-D/sip-in-impl01.txt

Best regards,

- vijay
--
Vijay K. Gurbani    vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216   Fax: +1 630 713 0184
_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits