similar to: No Static Payload Type

Hi all, Please find below the -01 update to draft-herlein-speex-rtp-profile, as submitted to the IETF. Regards Phil <p>-------------------8<-----------------------------------8<--------------------- <p><p>Internet Engineering Task Force Greg Herlein Internet Draft Jean-Marc Valin

Hello, What's the purpose of the 'sr' sdp parameter ? The sample rate is already given in the a=rtpmap line ? Simon Le dim 29/06/2003 à 12:12, philkerr@elec.gla.ac.uk a écrit : > Hi all, > > Please find below an updated Speex Internet Draft document. > > It would be good if we could book some time for discussion on Speex at the IETF > meeting in Vienna (scheduled

Hi all, Please find below an updated Speex Internet Draft document. It would be good if we could book some time for discussion on Speex at the IETF meeting in Vienna (scheduled for 14th July). The cutoff for submission is 9:00am EDT, (GMT -04:00), 30th June. Comments and feedback welcomed! Regards Phil

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

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

Hi All, Please find below an updated Vorbis-RTP Internet Draft document for review and discussion at the Xiph IRC meeting on Saturday. The changes in this version have been: Codebook caching mechanism Expanded SDP parameters Expanded MIME section Expanded introduction Packet loss section Minor tweaks and clarity changes to text There are probably some minor tweaks to the formatting needed

Hi everyone, Here's a follow-up on the two BoFs we've had about doing royalty-free codecs at the IETF. Well, the good new is that the proposal is now in IETF last call until January 20th (see below). No final decision has been made, so it's important to get as much support as possible for the Working Group proposal. You can see the ongoing discussion on the mailing list archive:

Hi everyone, Here's a follow-up on the two BoFs we've had about doing royalty-free codecs at the IETF. Well, the good new is that the proposal is now in IETF last call until January 20th (see below). No final decision has been made, so it's important to get as much support as possible for the Working Group proposal. You can see the ongoing discussion on the mailing list archive:

hi, i have strange problem with no rtp packets from asterisk after dns query. see pcap below centos6/asterisk 13.9 + chan_sip 172.23.0.3 - asterisk 172.23.5.1/2 - voip phones any ideas/hints? 1170 25.028206000 172.23.0.3 -> 172.23.5.1 RTP 214 PT=ITU-T G.711 PCMA, SSRC=0x334508F6, Seq=49318, Time=1442112256 1171 25.045556000 172.23.5.1 -> 172.23.0.3 RTP 214 PT=ITU-T G.711

Audio packets are running... 961 16.150421076 192.168.5.150 -> 192.168.5.25 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x6A3E0AF1, Seq=28402, Time=73280 962 16.170411284 192.168.5.150 -> 192.168.5.25 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x6A3E0AF1, Seq=28403, Time=73440 963 16.190381989 192.168.5.150 -> 192.168.5.25 RTP 214 PT=ITU-T G.711 PCMU, SSRC=0x6A3E0AF1, Seq=28404, Time=73600 964 16.210387990

On 7/16/15, Martin Leese <martin.leese at stanfordalumni.org> wrote: > Martijn van Beurden wrote: >> I would propose: 0000-0111 : (number of independent channels)-1. >> The channel order is defined through the >> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If >> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel >> order follows

Hello list, We're currently facing some issues concerning T.38 gateway faxing. This is a device used almost exclusively for receiving faxes. Calls are incoming to asterisk on a SIP trunk (sangoma netborder) using G711A. Gateway mode is activated in the asterisk dialplan towards a Cisco SPA 112 running firmware 1.3.5. We are using asterisk 1.8.13.0 with the T.38 gateway patch applied (I know I

Hi, some good news from IETF :) /alfred -------------- next part -------------- An embedded message was scrubbed... From: The IESG <iesg-secretary at ietf.org> Subject: [AVT] Protocol Action: 'RTP Payload Format for the Speex Codec' to Proposed Standard Date: Mon, 18 May 2009 06:26:11 -0700 (PDT) Size: 3867 Url:

Hi all, Below is the Vorbis RTP Internet Draft as sent to the AVT working group of the IETF. Comments and feedback is still welcomed from the Vorbis community. Cheers Phil ---------------------------8<-----------------8<------------------------ Network Working Group Phil Kerr Internet-Draft The Ogg Vorbis January 07, 2003 Community / OpenDrama

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

Hi Jack, > You're comments are welcome. Here they are... 3.1 RTP Header Payload Type (PT): I don't see an alternative to using a value of the dynamic range (96-127). IIRC, other ranger are reserved for fixed values assigned by IETF. "A dynamic payload type MUST be used - i.e., one in the range [96,127]." 3.2 Payload Header If you refer to RFC2119, please keep the capital

The latest revision of the draft profile for use of Speex in RTP is attached. We plan on submitting this - or a modified version of this, based on immediate feedback - to the IETF on Monday for consideration at the next meeting. Major differences in this revision are: - removed the discussion in the MIME section. It's a duplicate of the SDP discussion anyway, and may or may not match the

There appears to be a disagreement between the encoding given in the sources for Siren14 that are downloaded from Polycom (and the ITU, both are the same) and that implemented by codec_siren14.so. The latter agrees with the actual device. If I make a .sln32 file and run the encoder from ITU/Polycom with encode 0 foo.sln32 foo.siren14 48000 14000 the resulting file doesn't play back

lvqcl wrote: > Martin Leese wrote: >> Note that the channel order may not be defined. > > IMHO it doesn't matter in this place of documentation (which describes > default channel assignments for FLAC). Your proposed wording was: 0000-0111 : (number of independent channels)-1. The channel order follows SMPTE/ITU-R recommendations. The assignments are as follows: The

Hi, When have a incoming call from E1 to a extension FXS, and this extension is busy, the incoming call recive ring tone, and it is wrong. What can I do? Thanks in advance Pedro Here is the trace: asterisk-1*CLI> < Protocol Discriminator: Q.931 (8) len=41 < Call Ref: len= 2 (reference 66/0x42) (Originator) < Message type: SETUP (5) < Sending Complete (len= 4) < Bearer