Subject: Re: [Ieprep] Internet faults, VoIP demo, etc and others

From: [email-masked]
Date: Tue, 3 Dec 2002 17:37:38 EST

In a message dated 12/3/2002 3:52:30 PM Eastern Standard Time, [email-masked] 
writes:

> If you implement RTP correctly, the RTP control protocol provides feedback
> on the packet loss, latency and jitter at the other end [RFC 1889].
> 

But:

In a message dated 12/2/2002 1:42:11 PM Eastern Standard Time, 
[email-masked] writes:

> > 2. new call attempts would have been rejected
> 
> no- the congested link would not cause the SIP proxies to reject calls
> n

[MAP] Guess I'm missing something, since the RTP functionality mentioned by 
Colin is the type of thing that I thought would allow a call control 
application to know that it should stop trying to set up more calls. Scott 
(and others) say there is no way to do it.

Mike Pierce
Artel

---

From: Scott Bradner <[email-masked]>
Date: Tue, 3 Dec 2002 17:49:40 -0500 (EST)

> (and others) say there is no way to do it.

a client (i.e. single phone) that already has a call going to point
X could tell that there is a problem with getting to point X and might
not set up more calls to point X (if setting up more calls to the
same point was something that it wanted to do) but it would have
no way to know if calls to point Y would find any problems since
there is no way for the phone to know what in the path from
the phone to point X was causing the lossage and if that same 
thing (link I would guess) is also in the path to point Y

Scott
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 3 Dec 2002 17:55:24 -0500

Colin et al;

I thought that the RTP spec specifically does _not_ mandate that RTCP be
implemented to "implement RTP correctly". I distinctly remember arguing 
otherwise in AVT meetings and being shot down.

Regards
Marshall Eubanks

On Tuesday, December 3, 2002, at 05:37 PM, [email-masked] wrote:

> In a message dated 12/3/2002 3:52:30 PM Eastern Standard Time, 
> [email-masked] writes:
>
>
> since they have no knowledge of the congestio
>
> n
>
>
> [MAP] Guess I'm missing something, since the RTP functionality 
> mentioned by Colin is the type of thing that I thought would allow a 
> call control application to know that it should stop trying to set up 
> more calls. Scott (and others) say there is no way to do it.
>
> Mike Pierce
> Artel
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 03 Dec 2002 18:01:28 -0500

You would probably be shot down by the AVT chairs (with me lending cover 
from the microphone) if you claimed that RTCP is not needed for a 
compliant implementation. If the RTP spec says anywhere that RTCP is 
optional, please let me know and we'll fix this.

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 18:04:13 -0500

>otherwise in AVT meetings and being shot down.

Section 6 of draft-ietf-avt-rtp-new-11.txt says RTCP "SHOULD be used in all
environments, but particularly in the IP multicast environment" (although
the profile says that "the RTCP bandwidth for non-data-senders MAY be set
to zero when operating on unidirectional links or for sessions that don't
require feedback on the quality of reception").

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 03 Dec 2002 17:49:21 -0500

>(and others) say there is no way to do it.

The media doesn't necessarily follow the same path as the signalling, and
so the SIP proxy may not see the RTP reception quality reports.

Colin

---

From: Rohan Mahy <[email-masked]>
Date: Fri, 6 Dec 2002 12:06:36 -0800

On Tuesday, December 3, 2002, at 02:49 PM, Colin Perkins wrote:

>> [email-masked]
>> mentioned by

To be more specific.  It is extremely unlikely that SIP intermediaries 
would be privy to or care about RTCP quality reports.  The endpoints 
would decide that one or more media flows had insufficient quality, and 
would modify the session to modify or exclude those flows (possibly in 
favor of a lower-bitrate audio flow or a flow for text chat) or one end 
would simply terminate the session.

thanks,
-rohan