Subject: [Sipping] How to work with TISPAN...

From: "Warren, Dan, VF UK - Technology \(TS\)" <[email-masked]>
Date: Tue, 7 Jun 2005 09:34:42 +0100

Perhaps a little history is required from the 'telecom barbarians' side of the fence, although not too much as I wouldn't want to bore you all...

When 3GPP started defining IMS, SIP was selected as the session control protocol and a lot of things were proposed by 3GPP in isolation from the IETF community.  When the IETF community got wind of these abominations/developments (I am trying to stay neutral as to which side of the fence I now reside on here), they were rightly upset, and after much wailing, hammering of fists and gnashing of teeth, 3GPP brought their requirements to IETF and (IMHO) lots of good and useful work ensued.  Some of this, as has been pointed out, is for the good of the entire community; some of it is very sepcific to the requirements of 3GPP.  However, the overriding principle behind all of it was in line with IETF principles that none of this should break anything, and no walled garden should be erected as a direct result of the technical implementation (even if that implementation might end up behind a wall anyway).  This should not be news to many of you as you were there and helped make it happen.

TISPAN is now defining it's Next generation network (NGN) and one fundamental element of that is IMS.  Because it is IMS, then 3GPP have taken a close interest and one of the stated aims of 3GPP's work to make IMS access independent and of TISPAN in adopting IMS is to allow for the possibility of fixed/mobile convergence (and that isn't just about voice).  As such, the ultimate target here is for 3GPP to take TISPAN requirements and incorporate them into the technical solutions, specifications and protocols that are defined as part of IMS to provide a single, common architecture and protocol set.  There was recently a joint 3GPP and TISPAN meeting where TISPAN discussed what they wanted to do to the 3GPP IMS SIP profile in 24.229.  3GPP's reaction to some of the proposals was along the lines of 'this is where we were 5 years ago.  Learn from our mistakes.  Go to the IETF and work with them as we did'.  So, now you have a new set of requirements, but you can use the same working method - define extensions as you see fit, P-headers when you need to pinch your nose a bit and explain the best way to get these things done.  Some of the requirements are even more 'barbaric' than those that 3GPP came up with because they relate directly to voice call supplementary services which are regulatory requirements in many networks and so have to be supported to allow IMS to serve a voice service that at least looks and feels like that which is available now, even if it is VoIP.  

As for comments such as 'The basic idea of TISPAN and 3GPP NGN IMS is to be in a walled
garden... they want to be non-interoperable', if that were the case, TISPAN and 3GPP would not have ever gone along the path of bringing anything to IETF.  The reason 3GPP provided their requirements to you was because IETF told 3GPP that they were going the wrong way.  3GPP has seen the light(!) and is now trying to help TISPAN see the light too.  Whilst the bells and whistles that are being added to solve these requirements might not be to everyones taste, they are being added in such a way that if they aren't to your taste, you don't need to use them and the basic principles of interoperability should still apply as a result - fall back to vanilla SIP will (should) work and so the basic functionality to establish and maintain a session should work too.  3GPP and TISPAN are being guided by you, so if it becomes broken, you are party to the breakage as well.  There is sufficient SIP based voice deployments today for interoperability to be a real and significant (and wholly unspoken) requirement.

And 'since GSM-A is a private and top-secret club...' - well all I can say is go to their website and see what you can actually access.  If you really feel the need to read the very long, complex and entirely commercial and legal framework interconnect agreements that are hidden from public gaze, I pity you sincerely.  However, much of the technical work is public and GSM-A is very good at seeking the expert advice it needs on subjects that it is not entirely conversent with.  I'll tell you what is going on with the specific example in the relevant thread.

Ultimately TISPAN and 3GPP are trying to achieve something that for barbarians is pretty revolutionary - a call/session control mechanism and service implementation environment that is as far as it can possibly be, non discriminatory based on access technology.  Roland Jesske's draft is a first step in the direction of getting your help so that the garden is also as unwalled as it can be whilst also maintaining the service requirements that regulators impose on voice calls.  It is a collision of concepts and ethos, but the work that has been achieved with 3GPP shows it can be done.  I am sure that TISPAN are redrafting the requirements frantically to get them into a position where they are entirely understood so that the work on the related solutions can begin.  There are timescales involved, but ultimately what is important is a solution that meets the requirements.  If it was really about timescales and walled gardens, and not about trying to get something that can work with vanilla SIP, we wouldn't be on the path that the requirements draft sets us on.

Cheers

Dan Warren
Half barbarian half purist

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Banibrata Dutta
> Sent: 07 June 2005 05:01
> To: 'Drage, Keith (Keith)'; 'Dale Worley'; 'Sipping (E-mail)'
> Subject: RE: [Sipping] TISPAN
> 
> 
> We need to be careful when we say that all the reference 
> material (ETSI
> documents) shall suffice in understanding the requirements completely,
> because ETSI documents many a times refere to ITU-T 
> documents, which are not
> "as-free-as" ETSI documents. For personal use (AFAIK) you can 
> download upto
> 3 ITU-T documents for free from their website, again -- all 
> PDF's (after
> registering yourself -- again for free).
> 
> As far as IMS is concerned, I don't think there's any need to 
> refer to any
> ITU-T doc for understanding requirements, though if you start 
> digging really
> deep, you may need to!
> 
> Just for information!
> 
> cheers,
> banibrata dutta. 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Drage, Keith (Keith)
> Sent: Monday, June 06, 2005 11:15 PM
> To: Dale Worley; 'Sipping (E-mail)'
> Subject: RE: [Sipping] TISPAN
> 
> The current requirements document is in revision based on the feedback
> received so far.
> 
> ETSI made a decision a long time ago that all its published 
> deliverables
> would be available free of charge from its web site. All the 
> references made
> in the current draft are published deliverables. These will 
> all be in PDF
> format, so if you are a real IETF purist, you will not be 
> able to read them,
> but most of the rest of the world seem to manage.
> 
> If you go here: 
> http://www.etsi.org/services_products/freestandard/home.htm
> you will have to register, but registration merely requires 
> identifying
> yourself so ETSI can maintain usage statistics.
> 
> If you wish to have all ETSI published deliverables on a 
> media like DVD,
> then this will cost you - details at
> http://www.etsi.org/services_products/e-shop/home.htm, but 
> for the purposes
> of the small number of references in this draft, the free 
> route should be
> entirely possible.
> 
> regards
> 
> Keith
> 
> 
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On
> > Behalf Of Dale Worley
> > Sent: 06 June 2005 18:26
> > To: 'Sipping (E-mail)'
> > Subject: RE: [Sipping] TISPAN
> > 
> > 
> > I'm starting to lose my grip on what we're trying to 
> accomplish here.
> > 
> > As far as I can tell, ETSI is going ahead with defining 
> extensions to 
> > SIP to support features that network operators want.  At least 
> > initially, these would be used entirely within their proprietary 
> > networks.
> > And they want to
> > get them defined quickly.
> > 
> > But it would nonetheless be good for them if they got some 
> input from 
> > the IETF, both for good system design, and to improve 
> interoperability 
> > over the long term, if not the short term.
> > 
> > Obviously, ETSI is less interested in commentary on their 
> requirements 
> > than on their mechanisms.  But without fairly detailed information 
> > about their requirements, it's hard to make intelligent comments on 
> > the mechanisms.  To that end, I thing it would be a big 
> improvment to 
> > revise their document to include discussion of the feature 
> > requirements.  Currently, they only refer to various telco 
> documents, 
> > but I've only been able to find pointers to paper copies at 
> > significant prices (200+ euros).  It isn't going to generate much 
> > commentary if one has to pay over 1000 euros to discover what the
> > *requirements* are.
> > 
> > Dale
> > 
> > 
> > _______________________________________________
> > 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
> 
> 
> 
> _______________________________________________
> 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