Subject: RE: [Sipping] RE: draft-stein-great-00.txt

From: "Yaakov Stein" <[email-masked]>
Date: Fri, 7 Oct 2005 15:52:01 +0200

> Yaakov,
> 
> I for one thank you for this draft. I, like others, believe 
> that VoIP can ultimately produce a better user experience 
> than PSTN, and its good to see folks write down some of the 
> problems that need to be solved to get there.
> 
> What I am unsure about, is what specific work you are 
> proposing for ietf. Much of what is discussed are 
> implementation tricks and algorithms; i.e., jitter buffer 
> adaptation appraoches. Are you proposing that IETF should 
> somewhere standardize those?

As I wrote in the proposal for the GREAT BOF,
I suggest writing a series of BCPs,
describing good ways to make the VoIP
user experience better.

(I proposed a specific mechanism for PLC in the PWE
context a few years ago.)

I believe this work fits well into the new RAI area.
(Meanwhile, I am waiting for the transport ADs
to approve holding the BOF in Vancouver.)

> Some of the other problems you describe - high packet loss 
> and delay - are resolved either through overprovisioning or 
> through the various QoS mechanisms IETF has proposed over the 
> years. None of the QoS mechanisms are present on the public 
> Internet, but the barriers there are business related, not 
> technical. So, I am not sure whether you think there is IETF 
> work to be done there or not.

See my response to a similar question in a previous email.

> 
> Another item you mention in your draft and in the thread is a 
> standardized wideband codec. Are you proposing that IETF 
> standardize one?

Sounds like a good idea to me.
And we should design it from day one for the modern Internet
environment.

The G-series codecs put 90% effort into low rate, and 10% into low
delay.
It is critical for them to be CBR, and there is no attention to packet
loss, etc. 

Only the IETF has the motivation to design a codec for:
1) no 4kHz (or 8kHz) limitation 
2) high perceptual quality (not "toll quality")
3) not necessarily CBR
4) low delay
5) resilient to bursty packet loss

Y(J)S

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Fri, 07 Oct 2005 09:27:56 -0400

On Fri, 2005-10-07 at 15:52 +0200, Yaakov Stein wrote:
> I suggest writing a series of BCPs, describing good ways to make the VoIP
> user experience better.

It seems clear that if we want SIP to dominate telecommunications, there
are a whole host of deficiencies that need to be addressed.  True, there
are a lot of users who don't mind these problems, but there are a lot
who *do*.  Amusingly, at first sight, many of these problems seem to be
petty or uninteresting implementation details, but once you look at them
two or three times, you realize that constructing a good solution is a
difficult research problem.

> 5) resilient to bursty packet loss

You might want to inquire at the SIPforum.  They seem to have an
interest in upgrading the quality of deployed SIP systems, such as
pulling together BCPs and "standard feature sets".

Dale

---

From: "Henry Sinnreich" <[email-masked]>
Date: Fri, 7 Oct 2005 15:12:06 -0500

The assertion on codecs is quite amazing, if it is meant as a reproach to
the IETF.

>5) resilient to bursty packet loss

The IETF has published RFCs on the iLBC audio codec, and is doing a lot of
other work in this area.

- RFC 3951: Internet Low Bit Rate Codec (iLBC)

- RFC 3952: Real-time Transport Protocol (RTP) Payload Format for internet
Low Bit Rate Codec (iLBC) Speech

- RTP Payload Format for the Speex Codec
<draft-herlein-speex-rtp-profile-02>

The I-D <draft-stein-great-00.txt> could indeed use the council given
earlier on this discussion trail:

>please remove the PSTN nostalgia from the document

...and I would add; to any similar memos wherever they may be presented.

Thanks, Henry

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Friday, October 07, 2005 8:52 AM
To: Jonathan Rosenberg
Cc: [email-masked]; Sipping
Subject: RE: [Sipping] RE: draft-stein-great-00.txt

Y(J)S

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Oct 2005 13:44:33 +0200

Hi,

> 5) resilient to bursty packet loss

As AVT chair and having been part of the process of the publication of 
RFC 3951 (iLBC) I have the following comment. IETF is not suitable to do 
codec work at all. We are totally lacking the expertise to do good work 
in the source coding business. We are also lacking the working methods 
for determining if a codec proposal would be beneficiary.

iLBC was basically rubber stamping, the chairs ensured through IETF 
external reviewers that iLBC was mature enough. But none in AVT had 
sufficient expertise to provide much more than editorial comments on 
that RFC.

The only thing I see that IETF can provide is better requirements to 
people who know codecs to make them more suitable for IP and it´s 
properties. And I would actually quite strongly object against IETF 
doing more codec work.

 > <draft-herlein-speex-rtp-profile-02>

In regards to RTP payload formats, any codec desiring a RTP payload 
format are welcome to come to IETF for standardizing it. And they are 
also doing that, thus no surprise that you find that most of the used 
codecs have IETF standardized RTP payload formats. RTP payload format is 
something AVT WG knows well and have a lot of experience in. However RTP 
payload formats still requires some knowledge about both the codec and 
RTP to be designed successfully.

Cheers

Magnus Westerlund
AVT Chair
--

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]