Subject: [Sipping] SIP support for IN services

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 19 Apr 2002 10:23:45 -0500

Folks:

Enclosed is an I-D for review that describes SIP support for IN
services.  The I-D represents agreement of the IETF SIN (SIP/IN) design
team and is intended for publication as an informational RFC.  It has
been through Last Call in the IETF SIN DT and the comments of the WGs
identified in the To list of this email are now being solicited.

http://search.ietf.org/internet-drafts/draft-gurbani-sin-00.txt

Thanks,

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and eServices
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Apr 2002 17:31:15 -0400

Trimming to sipping.

I think this draft would benefit from an applicability statement of
sorts up front. There are definitely issues with this kind of approach.
It will pretty much require a b2bua unless the SIP element KNOWS that
the only services involved won't require it. It is limited to services
deployed in the PSTN. There are other ways to get those services without
this kind of approach. For example, to get an 800 number service, you
could alternatively have the proxy query a DB (using enum, for example),
to get the routing number. I don't want the readership to believe that
this is the IETFs preferred model for services in SIP. I know the draft
doesn't claim that, but an applicability statement clearly saying it
isn't would be a good thing, IMHO.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 Apr 2002 10:20:45 -0500

Jonathan:

Thanks for the comments; responses inline.

Jonathan Rosenberg wrote:

> the only services involved won't require it. 

The I-D contains a statement to that effect:

    It is not the intent of this draft to specify which SIP entity shall
    operate as a SSP; however, for the sake of completeness it should be
    mentioned that this job should be performed by SIP entities at (or
    near the) core of the network instead of the SIP end points
    themselves.  To that extent, SIP entities like proxy servers and
    Back-to-Back UAs (B2BUAs) may be employed.  Generally speaking, proxy
    servers can be used for IN services that occur during a call setup or
    teardown.  For IN services requiring media handling (DTMF), B2BUAs or
    proxies that actively control media gateways will be needed.

> It is limited to services deployed in the PSTN. 

The I-D also recognizes that:

      This draft is only applicable when SIP-controlled Internet
      telephony devices are to interoperate with PSTN devices.

> I don't want the readership to believe that

OK, no problem; just some guidance -- are applicability statements
paragraphs at the beginning of an I-D, or are they I-Ds in themselves?

Thanks,

- vijay

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 25 Apr 2002 14:06:36 -0400

>     proxies that actively control media gateways will be needed.

Thats just a statement of fact; what I am looking for is soemthing like
"this approach will require elements to be b2bua's. B2BUAs are frowned
upon because of their usage of call state, scalability issues, and
potential for removing service transparency".

> paragraphs at the beginning of an I-D, or are they I-Ds in themselves?

No, they are a statement at the beginning that discusses the
applicability and problems with the approach. See the infamous privacy
draft for an example of how the applicability statement gets placed and
worded. 

I would suggest something like:

This mechanism provides a way for SIP elements to make use of IN
services defined within the PSTN. It does not represent a general model
for providing of services within SIP. The approach has several
drawbacks. It is limited to providing only services defined within the
context of IN (many of which can be implemented within SIP without usage
of IN techniques). It is limited to services associated with calls
(presence and IM have no role). It will generally require SIP elements
to act as B2BUAs, which introduces fault tolerance, scale, and service
transparency issues. 

-JOnathan R.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 25 Apr 2002 14:24:52 -0500

[...]

Jonathan:

Some feedback on your suggestion:

> This mechanism provides a way for SIP elements to make use of 

> IN services defined within the PSTN. It does not represent a 

> general model for providing of services within SIP. 

This is fine -- there are several models for providing service in SIP;
this happens to a specific model that can be used when interworking
with the PSTN.

> The approach has several drawbacks. It is limited to providing 

> only services defined within the context of IN (many of which can 

> be implemented within SIP without usage of IN techniques). 

This I don't agree with, IMHO.  The prior example of using ENUM to
resolve a 800 number does not fit an IN service, in my mind anyway.
ENUM operates in the Internet; a DNS server is consulted, not a
PSTN data repository, for instance.  The approach outlined in the
I-D has the advantage that the data being accessed is in the PSTN
domain and is accessed transparently from the Internet.  While not
technically impossible, why duplicate the all the 800 number databases
in the Internet if we can access them transparently from the PSTN?

> It is limited to services associated with calls

The travails of a B2BUA are well documented in the SIP/SIPPING WG
email lists.  I am neither condoning nor endangering its use.  I
simply list it as a possible SIP entity where certain services can
be provided, without saying that an implementor MUST use a B2BUA.

Thanks,

- vijay