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

From: "Hemant Agrawal" <[email-masked]>
Date: Fri, 12 Apr 2002 19:15:03 -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: Bobby Sardana <[email-masked]>
Date: Sat, 13 Apr 2002 02:29:22 -0700

Comments inline!

> What about providing SIP services to existing SSPs.

The SIP for IN (SIN) is currently looking at IN interface with respect to
SIP.  The current SIN draft provides existing IN service access mapping.

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

This would imply the following:

a. Use CPL for new SCP like platform
b. Provide a SIP translation for existing SCP infrastructure.

For native SIP networks (a) would be useful. For hybrid, near term networks,
(b) would be useful. I am sure that the existing SCP vendors would also push
for (b).

> SCPs.

Easier in what manner? Deployment, implementation, management, or cost?

> Is their any significant work being done in this direction.

The SIP proxy players along with SCP manufacturers will be looking at the
services market. So, yes there is work being done in this area.

> Is it wise to do so?

Services generate revenue.

> stateful SIP Proxy server is required?

Mid-call features are supported by INFO method in SIP. If the INVITE
originated through a "Call Stateful Proxy" then yes the INFO will traverse the
same route.

regards,

Bobby Sardana.
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Sat, 13 Apr 2002 14:32:48 -0400

Hemant,

The charter of SPIRITS group is very different from what you describe.
SPIRITS deals with delivering the PSTN event notifications to the
Internet end-points.

The issues of SIP/IN interworking are worked in the SIN design team,
which is in the process of creating the first SIN informational RFC. The
current draft (Gurbani et al.) will soon be published. You can ask Vijay
([email-masked]) for the latest draft. If you want to join SIN,
please write to Hui-Lan ([email-masked]).

Igor

---

From: Igor Faynberg <[email-masked]>
Date: Sat, 13 Apr 2002 14:36:14 -0400

If I had seen Bobby's detailed response BEFORE I responded to the same
message, I would not have any need to respond. I fully agree with Bobby.

Igor

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 13 Apr 2002 21:24:51 -0500

> 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

---

From: "Hemant Agrawal" <[email-masked]>
Date: Thu, 18 Apr 2002 12:01:18 -0700

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

Hemant:

Best regards,

- vijay

---

From: Bobby Sardana <[email-masked]>
Date: Thu, 18 Apr 2002 21:07:40 -0700

The model you describe will work well for services where only a lookup is
needed. These are usually 800/888/877 like SCP services. For complicated
services where an "adjunct node" may be required along with SCP, e.g., calling
card service with prompts, a new framework would have to be designed and then
mapped to the INAP interface.

The question is why take this route at all! The answer is to modify existing
SCP platforms to incorporate CPL processing and provide mapping to SIP
interface. CPL based services can now be accessed via SIP interface and new SIP
services can be deployed on existing SCP infrastructure. Over time such
platforms will mature and will provide native SIP services. Also, the idea is
to provide a migration path for SCP evolution so that new SIP based services
can be deployed.

regards,

Bobby Sardana.
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Fri, 19 Apr 2002 12:08:59 -0400

Bobby Sardana wrote:
> needed. These are usually 800/888/877 like SCP services. [...]
> ...

Oh, no! It is precisely the "freephone" service that needs MUCH more
than a lookup. First of all, there is a "prompt and collect" with all
the messages passing back and force and many different pieces of service
logic that have to run--often concurrently--to service this. Second, an
essential part of such services is network queuing, which is really a
message-passing semaphore mechanism.

Igor