Speex dev - Aug 2004 - First draft for Speex RTP profile - Please send your comments

(sent on behalf of Federico Montesino Pouzols <fedemp@altern.org>)
 
        Hi, I like the draft, particularly because of its simplicity,
which is another pro of speex compared with other codecs. Some
comments:

<p>        - Reading section 3, I understand that frames cannot be
fragmented across different RTP packets, which seems quite
reasonable. I think a explicit statement on this would make the draft
even more clear.

        - I believe speex frames are little enough to fit in a packet
smaller than the usual path MTU. However, when RTP packets convey
multiple frames, one could use a high enough ptime value so that the
RTP packet size would exceed the path MTU. Normally, RTP payload
formats should avoid fragmentation or define its own fragmentation
mechanism (see RFC 2736). I think in this case it would be good to add
the constraint that the value of ptime should be such that the RTP
packet size does not exceed the MTU.

        - Section 7 indicates that RFC 1889 is updated by a work in
progress, but does not indicate that RFC 2327 is also updated by a
work in progress (draft-ietf-mmusic-sdp-new). Also, references number
2 and 4 are not referenced in the draft.

        - Regarding the MIME registration section, it lacks published
specification. I think it should reference the speex documentation as
well as the draft. Also, no contact person and change controller is
provided, and the "security considerations" parameter refers to RFC
3047.

        I attach a patch for some typos, I believe. Bye.

57c57
< main characteristics can be summerized as follows:

---
> main characteristics can be summarized as follows:
116c116
< 3.1 Multiple Speex frames in a RTP packet
---
> 3.1 Multiple Speex frames in an RTP packet
<p><p>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 242 bytes
Desc: signature.asc
Url :
http://lists.xiph.org/pipermail/speex-dev/attachments/20021027/b0f1447a/signature-0001.pgp

>         - Reading section 3, I understand that frames cannot be
> fragmented across different RTP packets, which seems quite
> reasonable. I think a explicit statement on this would make the draft
> even more clear.
I agree.
> 
>         - I believe speex frames are little enough to fit in a packet
> smaller than the usual path MTU. However, when RTP packets convey
> multiple frames, one could use a high enough ptime value so that the
> RTP packet size would exceed the path MTU. Normally, RTP payload
> formats should avoid fragmentation or define its own fragmentation
> mechanism (see RFC 2736). I think in this case it would be good to add
> the constraint that the value of ptime should be such that the RTP
> packet size does not exceed the MTU.
I agree.
> 
>         - Section 7 indicates that RFC 1889 is updated by a work in
> progress, but does not indicate that RFC 2327 is also updated by a
> work in progress (draft-ietf-mmusic-sdp-new). Also, references number
> 2 and 4 are not referenced in the draft.
I wasn't aware of a new SDP draft. I hope it does not change too much
things.
> 
>         - Regarding the MIME registration section, it lacks published
> specification. I think it should reference the speex documentation as
> well as the draft. Also, no contact person and change controller is
> provided, and the "security considerations" parameter refers to
RFC
> 3047.
> 
>         I attach a patch for some typos, I believe. Bye.
<p><p>--- >8 ----
List archives:  http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'speex-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.