search for: packetise

Hello. I am working on implementing RFC 5574 (RTP Payload Format for the Speex Codec) in the ffmpeg and have a question concerning it. It would be nice if somebody could answered it. * Chapter 4.1.1 Registration of Media Type Audio/Speex, subpart "Optional parameters" states these SDP optional parameters: vbr: variable bit-rate - either 'on', 'off', or 'vad'

Dear, is any way to change , the size of voice packets? I want to increase the quality by decreasing the size of each packets, because of bandwidth failure. ? thanks in advance Mani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081110/c1b2ed9d/attachment.htm

comment inline. On Wed, 16 May 2007, Jean-Marc Valin wrote: >> Page 3: >> >> To be compliant with this specification, implementations MUST support >> 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. >> The sampling rate MUST be 8, 16 or 32 kHz. >> >> There is a type above after (narrowband), there is a " extra

> Page 3: > > To be compliant with this specification, implementations MUST support > 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. > The sampling rate MUST be 8, 16 or 32 kHz. > > There is a type above after (narrowband), there is a " extra character. > > I don't understand what is the motivation to specify "SHOULD

Hello, I have a small LAN network connected through an Asterisk Server (Trixbox). I was looking to create my own custom made softphones, and I have been looking into how to transmit and receive via RTP. Would anyone know how the Asterisk RTP bridging works, and if there is any documentation on it? How is the RTP stream routed through the Asterisk server? Do I just give it the endpoints and

Hi Friends, Something I'd like to shed some light on if possible - how is it that a single ISDN conversation only uses 64K for bidirectional communication (using ulaw, correct?), but on several occasions now have seen references to ulaw voip conversations using 64K per side of the conversation, plus packet overhead (http://www.zytrax.com/tech/protocols/voip_rates.htm - seems to be down

http://bugzilla.mindrot.org/show_bug.cgi?id=1141 Summary: Is there a sound reason for MAX_MSG_LENGTH being 256KB? Product: Portable OpenSSH Version: 4.2p1 Platform: ix86 OS/Version: All Status: NEW Severity: enhancement Priority: P4 Component: sftp AssignedTo: bitbucket at mindrot.org

Hello Asteriskers, I'm confused about why Asterisk is not a SIP proxy and why exactly this can affect the performance of a large Asterisk system. I know that Asterisk acts as a useragent endpoint, but my doubt is why exactly Asterisk could overload the call flow if the RTP voice stream goes from the caller to the called party. Does someone know how many calls or pencentaje that could handle

On Thu, 17 May 2007, Jean-Marc Valin wrote: >>> Consider a device that only has enough ROM to store one set of >>> quantization tables (the limitation could also be about speed, network, >>> ...). If you specify MUST be able to decode, then it means that this >>> device simply *cannot* implement the spec *at all*. This is bad for >>> interoperability.

>> The main idea is that Speex supports many bit-rates, but for one reason >> or another, some modes may be left out in implementations (e.g. for RAM >> or network reasons). What we're saying here is that you should make an >> effoft to at least support (and offer) the 8 kbps mode to maximise >> compatibility. > > I understood this. But as you may know: the

Here my comments: Page 3: To be compliant with this specification, implementations MUST support 8 kHz sampling rate (narrowband)" and SHOULD support 8 kbps bitrate. The sampling rate MUST be 8, 16 or 32 kHz. There is a type above after (narrowband), there is a " extra character. I don't understand what is the motivation to specify "SHOULD support 8 kbps

>> Consider a device that only has enough ROM to store one set of >> quantization tables (the limitation could also be about speed, network, >> ...). If you specify MUST be able to decode, then it means that this >> device simply *cannot* implement the spec *at all*. This is bad for >> interoperability. > > For me: device which don't have all mode

On Wed, 16 May 2007, Jean-Marc Valin wrote: >>> The main idea is that Speex supports many bit-rates, but for one reason >>> or another, some modes may be left out in implementations (e.g. for RAM >>> or network reasons). What we're saying here is that you should make an >>> effoft to at least support (and offer) the 8 kbps mode to maximise >>>

Hi all We are about to send an updated version of the internet draft "RTP Payload Format for the Speex Codec" to the IETF AVT working group. Before submitting we would like your input, if you have any comments or input please send them to the mailing list. If we don't get any comments in 1 week (by 22. May 2007) we will go ahead and submit it to the IETF. Of course you can comment

Looks good to me. Jean-Marc Alfred E. Heggestad a ?crit : > Hi > > Please find an updated version of the Speex I-D attached. The only > change is addition of the copyright conditions in Appendix A, > as requested by Ivo. > > Many thanks for your input. > > I will give you a few more days before submitting to AVT working group > > > /alfred > > Ivo

Alfred E. Heggestad wrote: > <...> > > If we don't get any comments in 1 week (by 22. May 2007) we will go ahead > and submit it to the IETF. Of course you can comment on it also after it > has been submitted, but we would like to get the input from the Speex > community first.. > thanks for all the input. please find attached an updated version of the draft. I

Do not forget to add the "Copying conditions" to the RFC. Check http://wiki.debian.org/NonFreeIETFDocuments That page contains a section titled "Template for RFC authors to release additional rights". To follow that guideline a section like the following should be added: x. Copying conditions The author(s) agree to grant third parties the irrevocable right to

Hi Please find an updated version of the Speex I-D attached. The only change is addition of the copyright conditions in Appendix A, as requested by Ivo. Many thanks for your input. I will give you a few more days before submitting to AVT working group /alfred Ivo Emanuel Gon?alves wrote: > Do not forget to add the "Copying conditions" to the RFC. > > Check