Subject: [AVT] AW: questions/comments on the CLEARMODE draft

From: "Kreuter Ruediger" <[email-masked]>
Date: Wed, 1 Oct 2003 18:44:33 +0200

Hi Sebastien,
 
restricting Clearmode to "some" applications
or explicitly exclude "some" applications
sounds very complicated to me.
If we start to do this, which applications should be 
excluded/included and which not ? How do we handle
future upcoming applications not thought about today ?
 
It would like to keep this draft (i.e. this pseudo codec)
as simple as possible. This will allow simple implementation,
and is, BTW, in line with existing implementations in the field.
 
See also some comments below.
 
Best regards,
Ruediger

	-----Ursprüngliche Nachricht----- 
	Von: GARCIN Sébastien FTRD/DAC/ISS [mailto:[email-masked]] 
	Gesendet: Di 30.09.2003 13:50 
	An: Kreuter Ruediger 
	Cc: Tom Taylor 
	Betreff: RE: questions/comments on the CLEARMODE draft

	Hi ruediger,
	
	As you may have seen in your mailbox, I have questioned the authors of the new-SDP draft about the "data" and "audio" issue.
	
	The outcome of this discussion was that "data" should rather be used in non-RTP scenario and fits in fine with pure data connexions but not for ISDN 7khz voice applications.
	
	On the contrary, the use of m=audio... may not be appropriate for pure data connexions since RTP transport is not needed.

	> "is not needed" ??? Well, how do you replace the security features, which come inherently with RTP ? In a TDM replacement scenario I really wouldn't like to miss them.

	> 2nd comment: Some people think about usage of Clearmode for low bitrate video data. So, if we follow your argumentation, we would need a Clearmode for "audio", one for "data", one for "video", one for ...    You will not find "one" MIME type that fits for all scenarios.

	It would be possible to use a specific mapping depending on the ISDN Bearer Capability information element received at the VoIP MGC.
	
	e.g
	
	BC 01000 "unrestricted digital info" ---> m=data UDP...

	> If SG11 wants to stay with "data" for use over UDP, I would suggest a seperate IANA registration for this MIME Type / MIME Subtype combination. With a SG11 Standard you wouldn't even need an RFC, because you already have a standard to point to.

	> You should also screen the argumentation for the >introduction< of "audio/T.38". This will make call setup codec negotiation in a VoIP environment much simpler. I don't see why we should follow a contrary approach with Clearmode.

	BC 10001 "unrestricted digital info with tones/and announcements --->m=audio 12345 RTP/AVP 97
	                           a=rtpmap:97 CLEARMODE/8000
	                           a=ptime:10

	> There is no tone detection with "Clearmode" in the currently existing DSP code, of VoIP gateways. If tone detection is needed, then G.722 must be used for ISDN 7kHz voice.

	Another possibility would be to restrict the use of clearmode to "ISDN 7 khz audio"

	> As described above, this doesn't make sense.

	Any thoughts about this?

	Regards,
	Sébastien
	
	Garcin Sébastien
	France Télécom R&D
	+33 (0)1 45 29 64 96

.v*?V'^�:ڞ�h�ը�H��j躖��'�~����i����
bz���j)fj��b��?j�

---

From: Colin Perkins <[email-masked]>
Date: Wed, 1 Oct 2003 21:53:54 +0100

On Wednesday, Oct 1, 2003, at 17:44 Europe/London, Kreuter Ruediger 
> and is, BTW, in line with existing implementations in the field.

I would agree with this. The clearmode draft solves a clearly specified 
and well delineated problem, and I would not like to see its scope 
creep without very good reason. Emulation of other data circuits is 
best left to other payload formats or protocols (e.g. those under 
discussion in the PWE3 working group, or perhaps in the ITU).

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt