Subject: RE: [Sipping] ToIP Requirements Draft

From: "Guido Gybels" <[email-masked]>
Date: Sun, 24 Jul 2005 11:21:05 +0100

Radhika,

<<The main weakness of this framework is this: Transcoding entity that is an integral part of the ToIP architecture has not been taken into account for signaling and media transfer.>>

As I said before: ToIP should remain fully in sync with the wider SIP environment. If it would turn out to be the case that such wider provisions, including those for transcoding, need additional features, we should work with those working groups on amending them.

But you missed my point: it's easy to state that something might not be covered. What I (and others) need is demonstration of what is missing and proposals for addressing them. Your above statement is too vague in this respect.

Based on this, I still fail to see where the proposed ToIP framework itself is missing something. The ToIP draft does *not* replace the general transcoding mechanisms for SIP.

<<ToIP is just another application>>

And that is exactly what it should be. We haven't worked for years to mainstream ToIP only to now decide to go back to the "niche market" situation.

<<ToIP framework mandates that transcodings must be provided. So, the framework MUST reflect with the requirements considering transcoding as a part of it. By the way, the transcoding in SIP is an "indirect" outcome of this requirements. This important functional entity imposes new requirements for signaling, media transport, and QOS.>>

I can't parse the above sorry. And you missed my point: by definition, the framework can only refer to specific SIP based mechanisms for transcoding, it can and MUST NOT establish a separate one. I am not aware of any *new* requirements that would be needed other than the ones already part of the work people like Gonzalo and Arnoud have been doing as part of the transcoding work.

<<[RRR] As I explained above, you are missing the main point. For example, transcoding as a part of it needs to be addressed.>>

This is very tiresome. I'm not going to repeat myself, but I'll say, together with the others that tried to make this point, like Frank, that other than making a vague statement on transcoding, I have not seen any *specific* point that this document needs to address. Trying to read your mind is very difficult, so either you clearly state what exact point is missing, or I'm going to have to ignore this completely.

It *seems* from your vague statements that you believe that the transcoding mechanism in SIP is lacking some specific features that would be needed for transcoding of ToIP media. If that is the case, then kindly state what those are, preferably backed up with some relevant data or examples, and we can then work with the transcoding people on addressing them.

<<[RRR] Again, like PSTN-SIP GW, where the switching occurs and how does the signaling (e.g., conversion) and performance will have impact on ToIP users based on the switching GW and media transcoding entity.>>

Nothing of what you say has indicated a *specific* requirement for ToIP that would be different from any other media. The signalling and transport for ToIP should be exactly the same as for other media, that was the whole point of the exercise. Other requirements, like what service providers should offer as services and to what users is something that sits in the realm of business models and regulation and as such is well out of scope.

<<We just cannot say that a magic will happen and the ToIP use will have everything perfect transparently.>>

No one is saying that. Quite the contrary. We are saying that ToIP will use exactly the same channels and mechanisms as those available in mainstream markets for other media, like voice telephony for example. That is a key strategy to take RTT out of its niche and into the mainstream. We should therefore not infringe on that model by splitting ToIP off again in some way or another. Here is some interesting reading for you:
"The future of interactive texting", speech given at the Institute of Physics, London, 8 October 2003:
http://www.ictrnid.org.uk/docs/gg081003.pdf

<<The above clarifications provide you the clear idea what I have been suggesting.>>

Sorry, it failed to give me any clear idea whatsoever. I simply do not agree with the assertion that ToIP should introduce its own specific mechanisms for dealing with things like transcoding. If you believe that text media needs any specific attention with regard to transcoding, then the transcoding drafts are the ones you need to target, not the ToIP one.

I assume ToIP will be on the agenda for the Paris WG discussions, so it seems that the best way forward is to raise any specific issues you might have there and get agreement in the WG on what needs to be done and what draft is the appropriate document to put it in.

Regards,

Guido

Guido Gybels
Director of New Technologies

RNID, 19-23 Featherstone Street
London EC1Y 8SL, UK
Tel +44(0)207 294 3713
Fax +44(0)207 296 8069

*******************************************************************
This email and attachments (if any) must be swept for viruses before opening. Their contents may be confidential or privileged and are intended solely for the named recipient. If you are not the intended recipient and you have received this email in error you must not read or use this email and should notify RNID on: +44 (0) 20 7296 8282.

RNID, Registered Office 19-23 Featherstone Street, London EC1Y 8SL No. 454169 (England, Registered Charity No. 207720)

********************************************************************

_______________________________________________
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, 24 Jul 2005 22:03:00 +0100

Hi Guido, Radhika, folks,

At the risk of saying "me too", I sure hope that ToIP is just another  
application. If not, then we're doing a disservice to the users, and  
throwing away a great deal of work by a number of different people  
active in this area.

SIP needs transcoding - every blasted thing needs transcoding - at  
the risk of being just as painfully repetitive as the previous mails,  
so what? That's why there's a transcoding draft.

We are years beyond individual customised islands of klunky cobbled- 
together kit with a N! Babel of boxes needed to interconnect these.  
This framework shows just how simple things can be, and quite  
correctly does not drift off into things that are general parts of  
the overall XoIP architecture.

Please don't change the ToIP framework document - it does what it  
says on the tin.

all the best,
   Lawrence

> Radhika,
<snip>
> And that is exactly what it should be. We haven't worked for years  
> to mainstream ToIP only to now decide to go back to the "niche  
> market" situation.
>
> <<ToIP framework mandates that transcodings must be provided. So,  
> the framework MUST reflect with the requirements considering  
> transcoding as a part of it. By the way, the transcoding in SIP is  
> an "indirect" outcome of this requirements. This important  
> functional entity imposes new requirements for signaling, media  
> transport, and QOS.>>
>
> I can't parse the above sorry. And you missed my point: by  
> definition, the framework can only refer to specific SIP based  
> mechanisms for transcoding, it can and MUST NOT establish a  
> separate one. I am not aware of any *new* requirements that would  
> be needed other than the ones already part of the work people like  
> Gonzalo and Arnoud have been doing as part of the transcoding work.
<snip>
> Sorry, it failed to give me any clear idea whatsoever. I simply do  
> not agree with the assertion that ToIP should introduce its own  
> specific mechanisms for dealing with things like transcoding. If  
> you believe that text media needs any specific attention with  
> regard to transcoding, then the transcoding drafts are the ones you  
> need to target, not the ToIP one.
<snip>