search for: packetisation

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

...mes are 20 ms long. I expect most clients would > use 20 ms, as it corresponds to one packet. As to what we need to do if > the ptime is invalid, I'm not quite sure, though maybe as you say round > it up (or down?). I understand that speex needs multiple 20ms packets: for speex "packetisation interval MUST be a multiple of 20ms", but you have to provide a specification compliant with other ones: "ptime" can have any other value and there can't be a MUST there. Round it up is a much better idea: usually, 30ms is used when 20ms would introduce too much bandwidth overhe...

...00 for wide band operation, and 32000 for ultra-wide > band operation. Agreed. > > ptime: duration of each packet in milliseconds. > > http://www.ietf.org/rfc/rfc4566.txt specify that in the ptime definition: > "it is intended as a recommendation for the encoding/packetisation of > audio". Thus, I would recommend to specify the same text as in rfc3264 > for sdp offer/answer model: > > "If the ptime attribute is present for a stream, it indicates the > desired packetization interval that the offerer would like to > receive. The ptime...

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

...t > doesn't support G.729, you can't say it's broken if someone unexpectedly > start sending that. Of course, in the case of Speex, we try and do our > best... I'm not talking about codec proposal: you cannot send G729 to a UA that didn't offered it. While you can send packetisation interval of 30ms even if the UA offered that he wish to receive 20ms. I think anyway, that adding "mode=any" is fixing the mode issue, so it's now possible to specify that you don't support some of the modes. >> One possible way would be to use "mode=any" to clea...

...ation 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. > I understand that speex needs multiple 20ms packets: for speex > "packetisation interval MUST be a multiple of 20ms", but you have > to provide a specification compliant with other ones: "ptime" can > have any other value and there can't be a MUST there. > > Round it up is a much better idea: usually, 30ms is used when > 20ms would introduce...

...00 for narrow band operation, 16000 for wide band operation, and 32000 for ultra-wide band operation. ptime: duration of each packet in milliseconds. http://www.ietf.org/rfc/rfc4566.txt specify that in the ptime definition: "it is intended as a recommendation for the encoding/packetisation of audio". Thus, I would recommend to specify the same text as in rfc3264 for sdp offer/answer model: "If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater...

>> 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

...ny -> ALL modes are supported but mode=4 is prefered. The above would make sense and compliant application would be interoperable? right? That would be perfect for me, and I guess would be fine for you? >> I understand that speex needs multiple 20ms packets: for speex >> "packetisation interval MUST be a multiple of 20ms", but you have >> to provide a specification compliant with other ones: "ptime" can >> have any other value and there can't be a MUST there. >> >> Round it up is a much better idea: usually, 30ms is used when >> 20...

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

...ied in RFC 4566 [RFC4566] if the ptime attribute is present > for a stream, it indicates the desired packetization interval that > the offerer would like to receive. The ptime attribute MUST be > greater than zero. Note that the sender is still allowed to use a > different packetisation interval. Since Speex uses 20 msec frames, > if the ptime attribute is not a multiple of 20 msec, the value MUST > be rounded up to a multiple of 20 msec. Rounding up is mandatory to > satisfy bandwidth limitations. > > Implementations MUST support ptime of 20 msec (i....

...ation. As specified in RFC 4566 [RFC4566] if the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero. Note that the sender is still allowed to use a different packetisation interval. Since Speex uses 20 msec frames, if the ptime attribute is not a multiple of 20 msec, the value MUST be rounded up to a multiple of 20 msec. Rounding up is mandatory to satisfy bandwidth limitations. Implementations MUST support ptime of 20 msec (i.e. one frame per packe...

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

...ation. As specified in RFC 4566 [RFC4566] if the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero. Note that the sender is still allowed to use a different packetisation interval. Since Speex uses 20 msec frames, if the ptime attribute is not a multiple of 20 msec, the value MUST be rounded up to a multiple of 20 msec. Rounding up is mandatory to satisfy bandwidth limitations. Implementations MUST support ptime of 20 msec (i.e. one frame per packe...