[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sipping] SIP support for IN services



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
jdrosen@dynamicsoft.com                 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP