Subject: Re: [Sipping] TISPAN

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 04 Jun 2005 02:23:20 -0400

inline.

Miguel Garcia wrote:

>> You may want to clarify the context in which you expect these services 
>> to be
>> used.  Section 4 contains the sentence "The requirements in this document
>> are intended to result in a mechanism with general applicability for 
>> the NGN
>> TISPAN and NOT on the Internet.", which suggests that you are not 
>> expecting
>> these services to be used anywhere SIP is now used.  If that is so, 
>> why are
>> you floating this proposal in front of the IETF?
> 
> 
> Well, ETSI is defining those services for usage in the context of Next 
> Generation Networks that are built on top of the IP Multimedia Subsystem 
>  (IMS). ETSI has strong requirements in terms of compability with the 
> PSTN and interoperability with IMS. I believe ETSI does not have any 
> problem if the Internet adopts the realization of these services, I 
> would actually be very happy if that situation arises. But you must be 
> aware that we are following an architectural model (the IMS) that 
> perhaps the general Internet does not want to exactly follow.
> 
> All these factors make us think that the general Internet might not have 
> interest in this work.... but if it has, welcome, we are not precluding 
> usage.

I think it is essential that we allow interoperability between "vanilla" 
SIP clients and ones on an IMS network. I don't see any reason why any 
call feature would be applicable only to IMS or NGN or TISPAN or 
whatever network. We have, to date, considered certain extensions not 
applicable to the Internet because they made assumptions about network 
topologies and provider relationships that were not generally 
applicable. Those are applicability limitations of a much different sort.

As such, though I don't think the objective in IETF would be to 
standardize the way a service or feature has to work, if folks want to 
provide a feature and they think it requires an extension, we should go 
through the normal process of figuring out, here in sipping, whether or 
not that is a reasonable thing to do with SIP and how one might go about 
doing it.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.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: Miguel Garcia <[email-masked]>
Date: Mon, 06 Jun 2005 10:16:41 +0300

Jonathan Rosenberg wrote:

> SIP clients and ones on an IMS network. 

This is provided. The SIP, SDP and RTP that you can see hitting a 
vanilla SIP client is standard SIP, SDP, and RTP that is defined in a 
number of standard track RFCs. So I don't see there is an issue here.

> I don't see any reason why any 
> whatever network. 

Well, there are some extensions that assume an underlying architecture 
or even a business model. Sometimes the architecture of business model 
is not applicable to the Internet as a general. Take for example the 
Advice of Charge service. This service assumes that an operator is 
charging users on a service by service basis (and here by service I mean 
a general service, such as the establishment of a multimedia session). 
Well, you may agree or not with the business model, which I would prefer 
not comment here, but there is a bunch of people who want to apply it. 
And when applying that business model, the Advice of Charge service 
makes sense.

I believe our responsibility in the IETF is to provide the toolkit for 
those who want to apply those architectures and business models. On 
doing so we may find that one or more ideas might be generally 
applicable to the Internet (such as the case of the OMA PoC Answer 
Mode), in which case we should do the same sort of things as we did with 
the P-Answer-Mode header (I mean, make it a standard track header).

>We have, to date, considered certain extensions not 

I agree with you, as far as I know it has never been the goal of the 
IETF to standardize servivces, but features that enable services. We 
need to preserve this goal, and I will take it into account for further 
work.

> -Jonathan R.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland