Subject: [Sipping] ToIP Requirements Draft

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 20 Jul 2005 10:48:31 -0400

Arnoud:

I am providing few comments on the following draft (after being absence
for a long time):

http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-01.txt

Major comments are as follows:

1. Add new sections as follows:
*	Section 6.x: Terminal Mobility
*	Section 7.x: ToIP and Wireless LAN ToIP
*	Section Y: ToIP QOS Requirements
2. Section 7.1: Include ToIP GW between Cellular Wireless Network and
Wireless LAN

As usual as I did in the past, I will write texts for all of the above
sections and sub-sections. Minor comments about the detail requirements
will be provided when we all will be working together among the
co-authors of the draft.

How come that you have dropped my name from the draft as a contributor
if not as a co-editor?

I have my new email address: [email-masked] as I am in SAIC now.
If you want to communicate with me on one-to-one basis as you do with
all co-authors, please use this email. I am sorry that I did not inform
you related to change of my job before (better late than never).

Best regards,
Radhika

_______________________________________________
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: "Frank Shearar" <[email-masked]>
Date: Wed, 20 Jul 2005 16:14:24 +0100

Hi Radhika,

* Could you expand on what terminal mobility would cover? We culled all the terminal requirements from the draft for a later informational RFC (or possibly to submit to the sipdev work). If you mean requirements for things like, say, 3G phones and users running around, doesn't the session mobility work cover this?

* How does ToIP even know it's running over a wireless lan (as opposed to the internet, a wired lan, etc.)? It's all just IP, after all. What additional requirements do you see for wifi lans?

* I assume by "QoS requirements" you mean more than just the requirements in section 6.2.6 like "don't buffer longer than 300ms" or "keep the error rate below x%"? What additional requirements do you have in mind?

frank

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: 20 July 2005 15:49
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] ToIP Requirements Draft

Arnoud:
I am providing few comments on the following draft (after being absence for a long time):
http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-01.txt
Major comments are as follows:
1. Add new sections as follows:
·       Section 6.x: Terminal Mobility 
·       Section 7.x: ToIP and Wireless LAN ToIP 
·       Section Y: ToIP QOS Requirements 
2. Section 7.1: Include ToIP GW between Cellular Wireless Network and Wireless LAN
As usual as I did in the past, I will write texts for all of the above sections and sub-sections. Minor comments about the detail requirements will be provided when we all will be working together among the co-authors of the draft.
How come that you have dropped my name from the draft as a contributor if not as a co-editor?
I have my new email address: [email-masked] as I am in SAIC now. If you want to communicate with me on one-to-one basis as you do with all co-authors, please use this email. I am sorry that I did not inform you related to change of my job before (better late than never).
Best regards,
Radhika

*******************************************************************
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)

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Wed, 20 Jul 2005 12:09:02 -0400

Hi, Frank:

Inline [RRR].

Because of ToIP, the network architecture has been changed. For example,
media transcodings have become a part of ToIP arch. So, it is a whole
new kinds of networking for which we have to be concerned about. That
is, any end-to-end requirements for ToIP that we put, we have to
consider the transcoding entity, like end user devices, is an integral
part of the end-to-end architecture.

The requirement draft has missed some of those things to clarify this,
and it is NOT trivial.

Thanks for your questions.

Best regards,
Radhika

-----Original Message-----
From: Frank Shearar [mailto:[email-masked]] 
Sent: Wednesday, July 20, 2005 11:14 AM
To: Roy, Radhika (AEAD); [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Hi Radhika,

* Could you expand on what terminal mobility would cover? We culled all
the terminal requirements from the draft for a later informational RFC
(or possibly to submit to the sipdev work). If you mean requirements for
things like, say, 3G phones and users running around, doesn't the
session mobility work cover this?

[RRR] Yes, you are right. It is nothing fancy per se. Just to add
requirements from ToIP point of view where users may use ToIP instead of
audio for example jus to make sure that no requirements are missed even
if no new requirements come out.

* How does ToIP even know it's running over a wireless lan (as opposed
to the internet, a wired lan, etc.)? It's all just IP, after all. What
additional requirements do you see for wifi lans?

[RRR] It depends. For example, a vehicle is moving, but the ToIP user
has the dual mode device and the device itself and/or network-based
switch will detect WiFi and/or cellular wireless network.

* I assume by "QoS requirements" you mean more than just the
requirements in section 6.2.6 like "don't buffer longer than 300ms" or
"keep the error rate below x%"? What additional requirements do you have
in mind?

[RRR] Yes, this has to be there. Additional requirements may come from
media transcodings as it is a must for ToIP. No one has spelled out QOS
requirements that require media transcodings.

frank

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: 20 July 2005 15:49
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] ToIP Requirements Draft

Arnoud:

*******************************************************************
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)

---

From: "Guido Gybels" <[email-masked]>
Date: Fri, 22 Jul 2005 09:16:12 +0100

Radhika,

You wrote:

<<The requirement draft has missed some of those things to clarify this,
and it is NOT trivial.>>

I disagree. For example, terminal requirements do not belong in this document at all. The ToIP draft offers a framework to implement a standardised environment for supporting conversational text. Neither more nor less.

I completely disagree with the statement that it would be a "whole new kinds of networking". The whole point of this exercise was precisely to demonstrate that using *existing* standards and provisions, the same one used to provide VoIP services, can be used to support interactive text. The last thing we want is yet another "new" kind of networking.

The previous versions suffered seriously from lack of scope and also introduced a whole raft of stuff that doesn't belong in such a description of a standardised environment, like trying to mandate aspects that belong to the regulatory domain, or indeed statements of what ToIP terminals should do and not do. There was even stuff in there that tried to mandate how PSTN equipment should behave! None of that belongs in this document. We rightfully removed all of that from the document.

<<[RRR] It depends. For example, a vehicle is moving, but the ToIP user
has the dual mode device and the device itself and/or network-based
switch will detect WiFi and/or cellular wireless network.>>

You didn't answer the question: what has this got to do with the description of a SIP/RTP based framework for conversational text services? Nothing in ToIP descends into the transport layer after all.

<<[RRR] Yes, this has to be there. Additional requirements may come from
media transcodings as it is a must for ToIP. No one has spelled out QOS
requirements that require media transcodings.>>

The question is: are there any *specific* requirements for ToIP that need to be expressed, if so, what are they? If these are just *general* QoS requirements they don't belong in this document.

There will be other documents relating to ToIP, similar to what happens with other aspects of SIP or RTP or ... I have suggested we should write a separate call flow document for ToIP and there will likely be others.

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Fri, 22 Jul 2005 07:39:16 -0400

Guido:
 
Let us discuss among the co-authors of this document further as we did in the past. Arnoud and I had some email exchanges on this. In this way, we can minimize our differences.
 
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 a result, the requirements do not reflect much from the end-to-end networking from ToIP point of view, as if, ToIP is just another application . I have explained below.
 
Inline [RRR]
 
Best regards,
Radhika

________________________________

From: [email-masked] on behalf of Guido Gybels
Sent: Fri 7/22/2005 4:16 AM
To: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Radhika,

You wrote:

[RRR] 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.

[RRR] A framework does NOT mean some so-called high-level statements that devoid the functional entity like transcoding.

[RRR] So, unless you reconcile yourself with the above, it is will be very difficult to go for further in appreciating what I have pointed out.

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

[RRR] Forget about the previous draft. I edited the previous draft as a co-editor and contributor. In fact, I provided the first draft version including the table of context. You also contributed for the last time. So, there had been intense discussions. Let us talk about this new version draft. This draft also inlcludes PSTN-IP GW for ToIP and other things. Why do we need to speak specifically for the GW? Does it not mean that GW is a piece where a conversion occurs, and, thereby, we have to mention in the framework.

[RRR] In the same token, we also see the overall picture including media transcoding.

[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. The requirements need to clarify that this may happen, but ToIP needs transcoding. It may be over the LAN, cellular wireless switches, and/or IP wide area network. Requirements need to clearify what like to be seen by ToIP users on end-to-end basis. We just cannot say that a magic will happen and the ToIP use will have everything perfect transparently.

[RRR] For example, if transcoding entity is in the middle, what should be the expected call setup time and media transfer delay for each media for point-to-point and multipoint-to-multipoint call?  

[RRR] We do not view that ToIP users will ONLY be those who have problems in speaking or hearing. We consider that any users can use ToIP depending on convenience. So, what should the end-to-end delay requirements for ToIP users that include transcoding? We have to discuss all those aspects. We cannot just leave everything as a place holder without giving some clear direction.

[RRR] I am NOT talking about call flows documentation. The above clarifications provide you the clear idea what I have been suggesting. It is simply from ToIP endusers' requirements considering media transcoding as an integral part of the networking. Then, like PSTN-IP GW and cellular wireless network, we also include other entities like wireless LAN/WiFi, and Cellular-wireless LAN/WiFi GW for completeness.

Regards,

Guido

Guido Gybels

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Sun, 24 Jul 2005 21:23:44 -0400

Guido:
 
I am trying summarize again as I did for Lawrence as follows:
 
1. If ToIP is just another application as other applications are, then it is NOT a problem as you are saying. In this case, we have to limit ourselves as we do for other applications: ToIP <--> ToIP communications. The framework document is NOT doing this. In this case, we do not need transcoding and many other things as we are saying in this framework draft. Is it clear?
 
2. The framework draft is going beyond ToIP <--> ToIP communications. It is also dealing with ToIP <--> Non-ToIP real-time communications. In this case, it mandates transcoding as well. Is this clear?
 
3. The framework document also deals with PSTN-IP GW and cellular mobile network. In the same token, it also needs to deal with wireless LAN/WiFi and cellular wireless-WiFi interworking for completeness.
 
Hope this clarifies the things.
 
Now, we like to see what are your concerns with respect to the above, if there are any.
 
Best regards,
Radhika

From: Guido Gybels [mailto:[email-masked]]
Sent: Sun 7/24/2005 6:21 AM
To: Roy, Radhika (AEAD); [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

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

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Sun, 24 Jul 2005 22:24:51 -0400

Arnoud:
 
Let us further expand our discussions as follows (earlier high-level bullet lists were not clear enough):
 
1. The part of the framework draft that deals with ToIP <--> ToIP communications, we do not need to do anything new.
 
2. As the framework draft also deals with ToIP <--> Non-ToIP real-time communications (e.g, audio, audio-video), in this case, transcoding is needed. We need to explain signaling, functional features, and QOS requirements from ToIP <--> non-ToIP communications point of view. It may be pointed out that SIP transcoding draft is dealing with only signaling aspect of this, not QOS part. We have to put our requirements in the framework document.
 
In fact, item 2 is the MOST aspect of the framework document that makes ToIP transparent to all users.
 
3. The framework document deals with PSTN-IP GW and cellular wireless network. We also need to add wireless LAN/WiFi and Wireless LAN/WiFi-Cellular wireless network interworking aspect of this for completeness.
 
4. The framework draft deals with user mobility only. We also needs to add terminal mobility of ToIP user for completeness.
 
Let us discuss among the co-authors first for the above points for more in-depth discussions as we did in the past.
 
Best regards,
Radhika

From: [email-masked] on behalf of Roy, Radhika (AEAD)
Sent: Wed 7/20/2005 10:48 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sipping] ToIP Requirements Draft

Arnoud:

http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-01.txt <http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-01.txt> 

I have my new email address: [email-masked] <mailto:[email-masked]>  as I am in SAIC now. If you want to communicate with me on one-to-one basis as you do with all co-authors, please use this email. I am sorry that I did not inform you related to change of my job before (better late than never).

Best regards,

Radhika

---

From: "Guido Gybels" <[email-masked]>
Date: Mon, 25 Jul 2005 11:22:53 +0100

Radhika,

This conversation is not going anywhere. As Lawrence said, it does what it says on the tin. if you can't offer a clear, factual statement on what is missing and why (as opposed to some vague assertions), then I don't see what I can reasonably add to the debate.

The draft should indicate how to use available SIP, RTP and other relevant standards to implement a ToIP framework. It does enumerate where interworking with other networks and platforms might be required, which I believe to be appropriate. That interworking is covered between IP and other environments, which is why you have the PSTN-IP section.

I still don't understand what specifics about IP over wireless or WiFi would introduce that are of relevance to the ToIP framework, but I'm happy to be enlightened. Note: enlightenment <> vague statement that "it needs to be in there".

The whole point of the exercise is to show how existing standards and protocols can be used to implement ToIP alongside other services, like VoIP.

I hope *that* is clear.

Guido

Guido Gybels

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: 25 July 2005 02:20
To: lconroy; Guido Gybels
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Lawrence:

Let me clarify the things as follows:

Best regards,
Radhika

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 25 Jul 2005 07:16:09 -0400

Guido:
 
Arnoud is coming back, and will discuss all the issues among the co-authors. Then, we will have all the specific answers for all points for which I have raised.
 
Yes, I did not explain other that saying "it needs to be there" because I do not like to "OVERLOAD" this WG with detail discussions. We will have enough time and space for discussion each point among the co-authors.
 
There is also a fine line: Wireless LAN/WiFi and IP network. It is the same, but not quite the same environment. If you add cellular wireless network on the top of this, you get another interesting situation from mobility point of view in the lower layer (not IP layer). We will discuss among the co-authors, and you can raise as much technical issues as you can and we will see what to do about this.
 
ToIP as an application is not an issue. You are right that it will be dealt with like another application in SIP.
 
However, the framework document is dealing with ToIP <---> Non-ToIP real-time (i.e., audio, audio-video) "Interworking." That is, this "interworking" between the applications is the key aspect of the framework draft. In this aspect, we have to go further. I have reserved the detail discussion among the co-authors without overloading this WG.
 
The other aspect is the terminal mobility. We will also discuss this among the co-authors. Let us not overload this WG with this discussion.
 
In fact, my initial suggestion has been to discuss among the co-authors, not the entire WG yet.
 
Best regards,
Radhika

From: Guido Gybels [mailto:[email-masked]]
Sent: Mon 7/25/2005 6:22 AM
To: Roy, Radhika (AEAD); lconroy
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Radhika,

I hope *that* is clear.

Guido

Guido Gybels

-----Original Message-----
From: Roy, Radhika (AEAD) [mailto:[email-masked]]
Sent: 25 July 2005 02:20
To: lconroy; Guido Gybels
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Lawrence:

Best regards,
Radhika

---

From: "Frank Shearar" <[email-masked]>
Date: Mon, 25 Jul 2005 12:28:01 +0100

> bullet lists were not clear enough):

<snip>

> 2. As the framework draft also deals with ToIP <--> Non-ToIP
> real-time communications (e.g, audio, audio-video), in this case,
> transcoding is needed. We need to explain signaling, functional
> features, and QOS requirements from ToIP <--> non-ToIP
> communications point of view. It may be pointed out that SIP
> transcoding draft is dealing with only signaling aspect of this,
> not QOS part. We have to put our requirements in the framework
> document. 

OK, you mean stuff like, say, transcoding text into sign language or
something? What sort've QoS requirements do you have in mind?

While transcoding RFC 4103 into, say, what V.21 modems use can be done
by machine, for the next several years at least transcoding text to
voice or sign language (or the reverse) will take place with a human
intermediary. How would we impose QoS requirements on these people?

As for signalling & functional features, what do we need in addition
to the standard SIP functionality? SIP already gives us a means for
invoking transcoding services, session mobility, and the like.

> 3. The framework document deals with PSTN-IP GW and cellular
> wireless network. We also need to add wireless LAN/WiFi and
> Wireless LAN/WiFi-Cellular wireless network interworking aspect
> of this for completeness. 

Why do we need to define how interworking works for IP networks that
run over different link layers? How does a SIP UA even know that it's
connecting to an IP network that happens to run on WiFi, GPRS, or
whatever? 

> 4. The framework draft deals with user mobility only. We also needs
> to add terminal mobility of ToIP user for completeness.

The framework deals with the mobility of the User Agents. Perhaps the
title of section 6.9's misleading, but "ToIP User Agents SHOULD use
the same mechanisms as other SIP User Agents to resolve mobility
issues." is clearly about terminal devices. Isn't it?

frank

---

From: "Guido Gybels" <[email-masked]>
Date: Mon, 25 Jul 2005 16:15:57 +0100

Henry,

Thanks for that, couldn't agree more!

Guido

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]]
Sent: 25 July 2005 15:19
To: 'Roy, Radhika (AEAD)'; 'lconroy'; Guido Gybels
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Unfortunately the IP-nonIP cases are a mess as with all other applications and ToIP cannot avoid it as well as Guido says. This should give everybody an incentive to move to IP-IP everything, including VoIP and ToIP ASAP. True e2e IP with no evil intermediaries.
Thansk, Henry

---

From: "Guido Gybels" <[email-masked]>
Date: Mon, 25 Jul 2005 18:08:50 +0100

Radhika,

<<ToIP as an application is not an issue. You are right that it will be dealt with like another application in SIP.>>

Which means the framework draft is as it should be.

Any issues to do with mobility, transcoding and the like therefore are full part of the already established efforts that look at these and other issues and the drafts that correspond with them. Those drafts are the place to deal with it, not the ToIP framework draft and certainly not some separate mechanism outside the main SIP context.

Regards,

Guido

Guido Gybels

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 25 Jul 2005 17:10:44 -0400

Inline [RRR]

From: Guido Gybels [mailto:[email-masked]]
Sent: Mon 7/25/2005 1:08 PM
To: Roy, Radhika (AEAD); lconroy
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Radhika,

[RRR] Right. However, the present framework draft does NOT limit itself here. It goes further making the draft incomplete in those aspects as explained below.

[RRR] The present framework draft does deal with mobility (user), Network Interworking (only PSTN-IP, Wireless Celluar), and application interworking (ToIP-Voice). These are NOT complete. That is why, the present framework draft needs address the follwing to make it complete if the present framework needs to keep its format/table of context as it is in the context of SIP:

* Mobility: User + Terminal (not only user as does it now).

* Network Interworking: WiFi-Cellular + PSTN-IP (not only PSTN-IP-cellular) -> because mobility needs to be address in both wireless environments (not only cellular environment as it does now).

* Application Interoperability: ToIP-Non-ToIP real-time applications (e.g., audio, video) -> It is addressed partially now, not all apsects of it.

[RRR] Hope the clarifies the things further.

Regards,

Guido

Guido Gybels

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 25 Jul 2005 17:18:14 -0400

Henry:

Right!

That is why, the framework draft does NOT limit itself to peer-to-peer IP networking for ToIP networking. I would have been glad it would have done so. You can see my other emails.

Best  regards,

Radhika

PS: (as I explained in other emails)

Present framework draft addresses mobility in cellular wireless, but does not address mobility in WiFi. It does say interworking for PSTN-IP-cellular, but does not address WiFi-Cellular. It does address ToIP-Voice as application interoperability, but does not address all aspects of ToIP-Non-ToIP real-time applications interoperability.

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Mon, 25 Jul 2005 18:25:45 -0400

Frank:
 
I cannot agree more with you. In fact, your last point is the cream of all and removes all confusions.
 
Good that you have raised specific technical points.
 
Inline [RRR]
 
Best regards,
Radhika

From: Frank Shearar [mailto:[email-masked]]
Sent: Mon 7/25/2005 7:28 AM
To: Roy, Radhika (AEAD); [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

<snip>

[RRR] There are couple of steps: 1. ToIP-ToIP communications, 2. ToIP-Audio communication (point-to-pint, multipoint-to-multipoint), and 3. ToIP-AudioVideo communications (point-to-point, multitpoint-to-multipoint).

[RRR] For example, for real-time audio or audiovideo communications, people expect some end-to-end delay limit (e.g., of the order of 150 msecs oneway end-to-end delay between the source-destination codec). In this context, what do we expect for items 1, 2, and 3? We have to discuss what is our expectation and why in the ToIP framework document. That is why, we are coming together for discussions among the co-authors first what we like to do for these items.

[RRR] You must understand that transcoding is NOT coming directly in the picture for providing our QOS expectation because we will be addressing the requirements on end-to-end basis. (It may so happen that we may not be able to put an actual figure for now if we believe that mesaurement/experimental data for QOS for those items is not available.)

[RRR] My majopr concern is this: Just because of ToIP, we do not like to provide any impression that the degraded performance is acceptable. I would rather say that superior performance is still expected as ToIP will be used as another application of convenience (as opposed to ONLY ot the people who have difficulties for communications) for items 1, 2, and 3.

[RRR] I do not think that the ToIP framework draft addresses the this point at all. 

[RRR] Right. These are SIP functional entities including transcoding services. The only thing that has been left out whether these entities will have an impact on end-to-end QOS as stated above. The key is this: Transcoding will be used even for the ToIP-Voice point-to-point call. The question is this: What should be the performance expectation? As stated above, we should need to clarify those in the framework document for completeness.

[RRR] My concern is that ToIP-ToIP, ToIP-Audio, or ToIP-AudioVideo communications must NOT be provided with degraded performance. So, there has to a discussion what the perfromance expectations are with or without transcoding/intermediary entities.

[RRR] In general, your are right. However, the framework document addresses cellular wireless mobility only. That is why, if we need to address mobility in the framework document as it stands now, we MUST address for both cellular and WiFi. It is for completeness. Otherwise, we need to drop cellular mobility as well. Kindly see my other emails.

[RRR] I appreciate your suoperior observation. You are right. If we translate the entire document in the SIP layer like SIP UA, we could write the entire framework document only from the SIP application layer point of view. So, what we should do is to expand/modify this writeup as follows: Impact of terminal mobility and user mobility on SIP UA. In this way, we can expand the rquirements for mobility.

[RRR] In the same token, we do not need to write anything like link layer technologies such as cellular and WiFi because SIP UA is an application layer entity. The framework document needs to be re-written in this context taking ONLY the SIP application layer point of view. That is why, all co-authors are being requested to review the framework draft
frank

---

From: "Guido Gybels" <[email-masked]>
Date: Tue, 26 Jul 2005 09:06:16 +0100

Radhika,

You are confused. 

<<Frank said: The framework deals with the mobility of the User Agents. Perhaps the title of section 6.9's misleading, but "ToIP User Agents SHOULD use the same mechanisms as other SIP User Agents to resolve mobility
issues." is clearly about terminal devices.>>

To which you replied:

<<[RRR] I appreciate your suoperior observation. You are right. If we translate the entire document in the SIP layer like SIP UA, we could write the entire framework document only from the SIP application layer point of view.>>

If you agree with that statement as you do here, it's pointless to then go on and contradict yourself elsewhere by trying to reintroduce parallel mechanisms for interworking or transcoding OUTSIDE the SIP application layer.

Mobility for ToIP users is implicitly dealt with through "normal" SIP functionality. The framework draft DOES NOT introduce a separate mobility scheme. The same goes for transcoding and all the rest.

Again: if any of those aspects, like transcoding, are in your opinion missing something of relevance to support text as media, then the right place to address that is in the corresponding draft (in this example thus the transcoding draft). It DOES NOT belong as a separate entity in the ToIP framework as presented here.

Regards,

Guido

Guido Gybels

---

From: "Frank Shearar" <[email-masked]>
Date: Tue, 26 Jul 2005 09:15:07 +0100

> [RRR] There are couple of steps: 1. ToIP-ToIP communications,
> 2. ToIP-Audio communication (point-to-pint, multipoint-to-multipoint),
> and 3. ToIP-AudioVideo communications (point-to-point,
> multitpoint-to-multipoint).

> [RRR] For example, for real-time audio or audiovideo communications,
> people expect some end-to-end delay limit (e.g., of the order of 150
> msecs oneway end-to-end delay between the source-destination
> codec). In this context, what do we expect for items 1, 2, and 3? We
> have to discuss what is our expectation and why in the ToIP framework
> document. That is why, we are coming together for discussions among
> the co-authors first what we like to do for these items.

> [RRR] You must understand that transcoding is NOT coming directly in
> the picture for providing our QOS expectation because we will be
> addressing the requirements on end-to-end basis. (It may so happen
> that we may not be able to put an actual figure for now if we believe
> that mesaurement/experimental data for QOS for those items is not
> available.)

> [RRR] My majopr concern is this: Just because of ToIP, we do not
> like to provide any impression that the degraded performance is
> acceptable. I would rather say that superior performance is still
> expected as ToIP will be used as another application of convenience
> (as opposed to ONLY ot the people who have difficulties for
> communications) for items 1, 2, and 3. 

OK, I think I know what you're driving at with the phrase "end-to-end QoS": we deleted the part of the draft that said (something like) "end-to-end delays MUST be less than 2 seconds". In particular, we culled it because there's simply no way to enforce this, apart from it being inappropriate. Transcoding services like text<-->speech WILL introduce relatively large delays, often much greater than two seconds. We know this because we see it every day in our interworking tests.

But I'm now wondering: do the RFCs for VoIP stuff actually mandate end-to-end delays? (MANDATE, not "you won't get nice voice with delays more than n milliseconds.) I don't recall RFC 3550 or 3551 talking about QoS other than using RTCP to keep track of stats like delay & jitter & whatnot.

If they do, then we should edit the TEXT TRANSPORT RFCs (4102, 4103) to reflect these requirements.

> [RRR] I do not think that the ToIP framework draft addresses the this point at all. 

Well, no, of course it doesn't. It can't. That's like putting something like "the user MUST answer his phone within 32 seconds of his SIP device first ringing." In fact, even if we could do this, we shouldn't: we've no idea what new, unanticipated transcoding services might pop into existence the day after we publish this RFC.

As for T.140<-->V.21 transcoding the draft says all it needs to, in section 7.8.

> [RRR] Right. These are SIP functional entities including transcoding
> services. The only thing that has been left out whether these
> entities will have an impact on end-to-end QOS as stated above. The
> key is this: Transcoding will be used even for the ToIP-Voice
> point-to-point call. The question is this: What should be the
> performance expectation? As stated above, we should need to clarify
> those in the framework document for completeness.

> [RRR] My concern is that ToIP-ToIP, ToIP-Audio, or ToIP-AudioVideo
> communications must NOT be provided with degraded performance. So,
> there has to a discussion what the perfromance expectations are with
> or without transcoding/intermediary entities.

Certainly text-text communications will work wonderfully. As soon as you're talking about proper transcoding (text<->video, for instance) you will experience degraded performance in the sense that a sentence communicated on one end will arrive much later at the other end than if there was no transcoding. There's no way we can avoid that. And people receiving a call from a text user running through a transcoding service WILL know there's something funny going on because of latency and the like. That's why RNID TypeTalk operators say "you're receiving a call from a text telephone" and ask if you're familiar with using the service. That way you know to be more patient than you'd otherwise be.

> [RRR] In general, your are right. However, the framework document
> addresses cellular wireless mobility only. That is why, if we need
> to address mobility in the framework document as it stands now, we
> MUST address for both cellular and WiFi. It is for
> completeness. Otherwise, we need to drop cellular mobility as
> well. Kindly see my other emails.

No, the draft doesn't speak of cellular wireless mobility at all. The only mobility in the draft is SIP's concept of mobility, which is why section 6.9, the "User Mobility" section, just says "do what other SIP applications do".

> [RRR] I appreciate your suoperior observation. You are right. If we
> translate the entire document in the SIP layer like SIP UA, we could
> write the entire framework document only from the SIP application
> layer point of view. So, what we should do is to expand/modify this
> writeup as follows: Impact of terminal mobility and user mobility on
> SIP UA. In this way, we can expand the rquirements for mobility.

> [RRR] In the same token, we do not need to write anything like link
> layer technologies such as cellular and WiFi because SIP UA is an
> application layer entity. The framework document needs to be
> re-written in this context taking ONLY the SIP application layer
> point of view. That is why, all co-authors are being requested to
> review the framework draft

I don't understand what you mean. What part of the draft isn't from the "SIP application layer point of view"? There's some stuff about interworking with existing, legacy realtime text telephony systems, but the SIP stuff is all, well, SIP. Since SIP only exists in the (OSI model) application layer, I'm not sure what you mean.

frank

---

From: "Guido Gybels" <[email-masked]>
Date: Tue, 26 Jul 2005 08:52:37 +0100

Radhika,

<<<GG: Which means the framework draft is as it should be.>>
<<[RRR] Right. However, the present framework draft does NOT limit itself here. It goes further making the draft incomplete in those aspects as explained below.>>

Not it DOES NOT and SHOULD NOT go further. It does reiterate a number of points that are of particular relevance to ToIP and then simply refers back to SIP or any other relevant standard. The framework DOES NOT and SHOULD NOT attempt to go beyond. It SHOULD NOT try to introduce a parallel track of requirements for things like mobility other than to refer to the appropriate SIP mechanism for dealing with such matters.

The same goes for the interworking stuff: the framework DOES NOT and SHOULD NOT introduce separate interworking arrangements, nor separate transcoding arrangements, etc. It IS right however for the framework to point to such topics of particular relevance to ToIP implementations and then point to the relevant SIP mechanism for dealing with this.

<<[RRR] The present framework draft does deal with mobility (user), Network Interworking (only PSTN-IP, Wireless Celluar), and application interworking (ToIP-Voice).>>

It does NOT in the sense you mean: the draft only indicates these as topics of importance (based on an understanding of what actual users do with interactive text, like for example transcoding from voice to text through human operator based relay services). ToIP SHOULD NOT add parallel mechanisms or protocols for dealing with these, rather all of these MUST be dealt with as part of already ongoing SIP work, thus truly keeping ToIP full and integral part of the SIP environment, rather than creating an offshoot.

Regards,

Guido

Guido Gybels

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 26 Jul 2005 16:19:46 -0400

Frank:
 
Let us complete the discussions among the co-authors first as we are very close after this upcoming IETF meeting.
 
We are almost there, and let us discuss the following among co-authors as follows:
 
1. We need to make clear that ToIP itself and ToIP-Non-ToIP-Applications interworking QOS expectations with respect to 150ms that is considered as a reference for the best quality. We are not imposing anything. We are just providing the direction to the industry. What you have said, we will revisit this issue among the co-authors. 
 
2. You have brought nice explanations for ToIP-Voice (Non-ToIP) QOS. That is fine. We can also clarify the fact of ToIP-Voice (Non-ToIP) QOS from both person with difficulties and normal persons (without difficulties - use of ToIP as a matter of convenience).
 
3. SIP does not re-emphasize its QOS because it is capable to provide QOS whatever quality is provided for the best quality services. NSIS, InterServ, and many others are working for QOS keeping only real-time application - SIP in view first (e.g., starting 150ms as the target). Now, ToIP-Non-ToIP Real-time Application interworking needs to address its own QOS expectations. It does not mean that we have to put hard figures for it because it will use transcoding. Let us not hide behind the screen for QOS. It will be mistaken.
 
4. We will examine all RFCs to see how and what we can emphasize for QOS in ToIP.
 
5. ToIP SIP UA mobility needs to be further clarified considering both terminal and user mobility.
 
6. ToIP draft have two detail sections PSTN/ISDN and Cellular Circuit-Switched Text Telephony services. It implies, in the draft interworking, with IP network as well. In this context, the missing part is interworking with WiFi. Let us discuss this among the co-authors first after this IETF meeting.
 
Best regards,
Radhika

From: Frank Shearar [mailto:[email-masked]]
Sent: Tue 7/26/2005 4:15 AM
To: Roy, Radhika (AEAD); [email-masked]
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

frank

---

From: "Roy, Radhika \(AEAD\)" <[email-masked]>
Date: Tue, 26 Jul 2005 16:22:59 -0400

It is NOT about parallel mechanisms. It is about completeness.
 
Kindly see how Frank is bringing objective arguments to close the gaps in technical points. Also see my replies. 
 
Best regards,
Radhika

From: Guido Gybels [mailto:[email-masked]]
Sent: Tue 7/26/2005 3:52 AM
To: Roy, Radhika (AEAD); lconroy
Cc: [email-masked]
Subject: RE: [Sipping] ToIP Requirements Draft

Radhika,

Regards,

Guido

Guido Gybels