Subject: RE: Question on RTP

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 21 Mar 2000 01:37:13 -0800

--> [email-masked] writes:
		>I like to add one more question:
		>Is it absolutely necessary that both direction use the same
type of
		>codec ?

		No.
		
		This is rather undesirable for vocoders or implementations
employing advanced echo cancellation, intelligent jitter buffer management
or a host of other DSP or voice-related properties.

		From my reading of the RFC, it is also equally possible for
either side to chop-and-change between vocoders at any point in time
(without SIP message exchange). Supporting this mixing and splicing of
vocoders significantly complicates the playback engine - the ability will
most likely be unsupported on simpler implementations or at best may cause
small audio glitches.

		It would be nice if the caller could force the callee to
agree on a single common vocoder if it doesn't support the use of multiple
vocoders. [Making the SDP session closer to a true two-way media exchange
rather than simply two disjoint vocoder packet flows in each direction.]

		One approach might be to place an updated SDP body in the
ACK where the SDP body has only one media format selected. The RFC currently
prohibits changing the SDP body in the ACK (unless the INVITE had no SDP
body). Does changing the body introduce any major problems or
inconsistencies ? 

		Furthermore, IMO it would be desirable if the callee could
indicate their vocoder preference by ordering the list of RTP media format
values in the 183/200 response.

		How have other people tackled this problem ? Are there any
drafts or FAQ on these subjects. 

		Cheers,

		Robert.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 27 Mar 2000 22:16:07 +0930

>most likely be unsupported on simpler implementations or at best may cause
...
>drafts or FAQ on these subjects. 

The RTP specification is written in such a manner that changing the codec
on the fly is acceptable behaviour, and is something an implementation
should be robust to. That said, I'd expect this is an unusual event, so a
small audio glitch is unlikely to be a problem when it occurs.

Colin

---

From: Stephen Terrill <[email-masked]>
Date: Wed, 29 Mar 2000 22:39:37 +0200

interesting implications on resource reservation ... ?

..//Steve