Subject: AW: [Sipping] TISPAN

From: "Stastny Richard" <[email-masked]>
Date: Sat, 4 Jun 2005 11:27:34 +0200

Well said, Jonathan!
 
> 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.
 
They do. The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled
garden and not in central park, becauae this is insecure and to be sure of  this 
they want to be non-intereoperable.
 
regards
Richard

________________________________

Von: [email-masked] im Auftrag von Jonathan Rosenberg
Gesendet: Sa 04.06.2005 08:23
An: Miguel Garcia
Cc: Sipping (E-mail)
Betreff: Re: [Sipping] TISPAN

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

_______________________________________________
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: lconroy <[email-masked]>
Date: Sun, 5 Jun 2005 00:21:58 +0100

Folks,
Now now, Richard. With the tone of all of these reactions, why do I get 
a feeling of Deja Vu from 1996?
The doc from ETSI TISPAN reflects their model of providing services, 
and their model of network interconnection.

I share many folks discomfort at the overall idea of a mesh of walled 
gardens with tunnels between them.
However ... if these fine folk want to use this model (and pay us all 
to build the fine Rococo kit it entails), then it is probably better 
that the stuff they do behind these closed walls is at least able to be 
decoded, if not fit for decent open (Internet) society.

As they have been thinking this through for a while, it should come as 
no surprise to ETSI members that this mindset informs the text. You 
could argue that the same is true for docs written from an "IETF" 
perspective.

Despite indications to the contrary, they *are* trying to get some 
specs out the door this side of the next millennium.
It's hardly a shock that they have NOT spent their time developing a 
grand unified theory that is applicable anywhere, any time, by any box, 
using every possible conceptual frameworks on what things are and how 
they connect.
(That's the job of "the SIP community" :)

As Keith said, there may well be a need for intermediate nodes to 
ensure that "plain" SIP phones can engage in these services.
This is why, I guess, they always talk about Session Border Controllers 
- as well as curing World Hunger, they act as the glue between the real 
world and the nether world.
[It is left as an exercise for the student to decide which is which].

Jonathon is (as usual) precise in pointing out that this is going to 
require a set of detailed work items to be processed in SIPPING, before 
a set of work items can begin in SIP to deal with this.
This is going to take a LONG time, and it is honest to spell this out 
at the start - there is zero chance of hitting the 2005 timeframe for a 
solution for all of these items through the IETF, IESG, RFC-ED, and 
IANA (for the realisation of these requirements).

It did appear to many curmudgeons that 3GPP/3GPP2 "bounced" a lot of 
items into the IETF process with short deadlines "or the world would 
end".

I, for one, appreciate the attempt by TISPAN folk to do the right thing 
and start the process early, rather than come out with a set of fully 
formed requirements set in stone that require blessing. Been there, 
seen it, done it - didn't like it.

You may be correct in the comment that these strange places will end up 
being non-interoperable with the rest of the known universe - given the 
scope of the required work and the difference in mindsets, this many 
not be feasible in anything LIKE ETSI/ITU's planned timeframes.

So what? We will end up with unspeakable acts going on, but it will go 
on behind closed walls, with closed pipes carrying the *** between 
them.

However, that is going to make any attempt to provide an eventual 
solution/migration that permits interworking between the (some might 
say, sane) way of doing things on this side of the wall and the 
"country practices" that go on over there really ugly. Do we REALLY 
want that?

all the best,
   Lawrence

> they want to be non-intereoperable.
---------------------------------------
lawrence conroy    |tel:+44-1794-833666

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 06 Jun 2005 10:22:44 +0300

Inline comments.

> they want to be non-intereoperable.

Richard:

I cannot disagree more with your words. I am trying to recall from my 
memory one single point where a vanilla SIP client couldn't interoperate 
with a SIP client connected to the IMS or to an NGN network, and 
honestly speaking, I can't recall any. The only thing that comes to my 
memory was that, at some point in time, 3GPP required all the sessions 
to use preconditions, so interoperability with those vanilla SIP clients 
  that did not implement preconditions wasn't possible. This limitation 
was relaxed in the Release 6 of the 3GPP specifications, so once more, I 
don't recall any point of non interoperability.

/Miguel

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