Subject: Re: [Sipping] SIP support for IN services

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Jun 2002 12:46:57 -0400

Scanning old emails; wanted to respond to this one:

Vijay K. Gurbani wrote:
> Jonathan Rosenberg wrote:
> [...]
>  > I would suggest something like:
> 
> Jonathan:
> 
> Some feedback on your suggestion:
> 

>>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.

Nothing in the enum protocol that I recall reading prevents the DNS 
server from accessing a back-end DB, such as something in the PSTN, in 
order to satisfy the query. Do not confuse access with the location and 
storage of the data being accessed. I could equally well use LDAP to 
access an 800 number database, that does not require me to replicate the 
DB elsewhere, just for their to be an LDAP hook.

The essence of the model in your doc is that the *access* to the 
services in the PSTN, which is through the IN, is assumed immutable, and 
thus the model you have. That is a very strong assumption, and I am 
arguing that if you change it, you get a whole other approach (and a 
simpler one, IMHO).

>>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. 
> 
> 
> 
> 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.

How can you avoid that? If the SCP doesn't *know* that the SSP is a 
proxy, how can you preclude the SCP from telling the proxy it can't do 
things that a proxy can't do?

-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

_______________________________________________
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: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 19 Jun 2002 09:50:03 -0500

Jonathan Rosenberg wrote:
>>> 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). 
>>

Just as there can be an LDAP hook, or a DNS server hook, there can also
be a 'SIP hook', so to speak, which uses the techniques described in
the document.  Furthermore, the 'SIP hook' is more integrated with the
the call model (or protocol state machine) processing the request, thus
providing for other services which may not be query-response in nature.

> things that a proxy can't do?

The SCP does not know that, the service provider does.  For services
which occur primarily during call setup and teardown, a proxy can be
used.  For other services which include media manipulation, dialog
manipulation, a B2BUA will be necessitated.  The technique described
in the document are just as applicable to a proxy or B2BUA since they
essentially use the same SIP state machines to trigger the services.

Thanks,

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