From Even.roni@huawei.com Tue Feb 1 03:42:02 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A17353A6914; Tue, 1 Feb 2011 03:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.028 X-Spam-Level: X-Spam-Status: No, score=-103.028 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qlE53xc-9Ld; Tue, 1 Feb 2011 03:41:53 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 9BB393A68F3; Tue, 1 Feb 2011 03:41:52 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFX004WNSMTX8@szxga04-in.huawei.com>; Tue, 01 Feb 2011 19:44:54 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFX00HSISMTZI@szxga04-in.huawei.com>; Tue, 01 Feb 2011 19:44:53 +0800 (CST) Received: from windows8d787f9 (bzq-79-183-9-180.red.bezeqint.net [79.183.9.180]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFX00ABUSMF4O@szxml01-in.huawei.com>; Tue, 01 Feb 2011 19:44:53 +0800 (CST) Date: Tue, 01 Feb 2011 13:40:45 +0200 From: Roni Even To: 'Robert Sparks' , iesg-secretary@ietf.org Message-id: <002301cbc204$e48acaf0$ada060d0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h3ZT1OjmoFbvuviAr9ohmw)" Content-language: en-us Thread-index: AcvCBN0ER2/8flVdQKq1wlTsKcUMpA== Cc: payload@ietf.org, draft-ietf-payload-rfc4695-bis.all@tools.ietf.org Subject: [payload] Request to publish draft-ietf-payload-rfc4695-bis-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 11:42:02 -0000 This is a multi-part message in MIME format. --Boundary_(ID_h3ZT1OjmoFbvuviAr9ohmw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, I'd like to request that draft-ietf-payload-rfc4695-bis-00, RTP Payload Format for MIDI, be published as Standard Track RFC. I've reviewed the draft in detail, and the AVT working group was given the opportunity to comment. The draft is documented in sufficient detail to meet the registration requirements, and doesn't conflict with other work in AVT. Accordingly, please consider it for publication. Thanks, Roni Even Document Shepherd Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through a Working Group last call and people had enough time to review it. Considering that this document is an update to an existing RFC addressing errata found in implementation the document Shepherd feels that the review was satisfactory. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist and idnits ).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The idnits tool resport some comments and one warning which are OK. The document does not change the current media subtype registration so there was no need to review it. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? No such sections (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The first version of the document came out in 2007 and the document was kept alive in order to capture any errata that will be discovered. The authors now feel that the implementations are stable and that it is time to publish the update. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are existing implementations and this update for RFC 4695 is based on issues that were found by implementers. --Boundary_(ID_h3ZT1OjmoFbvuviAr9ohmw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Robert,

I'd like to request that draft-ietf-payload-rfc4695-bis-00, RTP Payload Format for MIDI, be published as Standard Track RFC.

 

Thanks,

Roni Even

 

Document Shepherd Write-Up

 

(1.a) Who is the Document Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the

        document and, in particular, does he or she believe this

        version is ready for forwarding to the IESG for publication?

 

The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication.

 

  (1.b) Has the docu both from key WG members

        and from key non-WG members? Does the Document Shepherd have

        any concerns about the depth or breadth of the reviews that

        have been performed? 

 

The document went through a Working Group last call and people had enough time to review it. Considering that this document is an update to an existing RFC addressing errata found in implementation the document Shepherd feels that the review was satisfactory.

 

  (1.c) Does the Document Shepherd have concerns that the document

     &nb sp;  from a particular or broader perspective,

        e.g., security, operational complexity, someone familiar with

        AAA, internationalization or XML?

 

No concerns

 

 

  (1.d) Does the Document Shepherd have any specific concerns or

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he

        or she is uncomfortable with certain r

        has concerns whether there really is a need for it. In any

        event, if the WG has discussed those issues and has indicated

        that it still wishes to advance the document, detail those

        concerns here. Has an IPR disclosure related to this document

        been filed? If so, please include a reference to the

        disclosure and summarize the WG discussion and conclusion on

        this issue.

No Concerns

 

(1.e) How solid is the WG consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with

        others being silent, or does the WG as a whole understand and

        agree with it?

 

This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft.

 

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme

     ; & nt? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It

        should be in a separate email because this questionnaire is

        entered into the ID Tracker.)

 

No

  (1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits).Boilerplate checks are not enough; this check needs to be thorough. Has the document m et all f needs to, such as the MIB Doctor, media type and URI type reviews?

 

The idnits tool resport some comments and one warning which are OK.

The document does not change the current media subtype registration so there was no need to review it.

 

  (1.h) Has the document split its references into normative and

        informative? Are there normative references to documents that

        are not ready for advancement or are otherwise in an unclear

       &nb sp;state ences exist, what is the

        strategy for their completion? Are there normative references

        that are downward references, as described in [RFC3967]? If

        so, list these downward references to support the Area

        Director in the Last Call procedure for them [RFC3967].

  

 

References are split

 

(1.i) Has the Document Shepherd verified that the document IANA

        consideration section with the body

        of the document? If the document specifies protocol

        extensions, are reservations requested in appropriate IANA

        registries? Are the IANA registries clearly identified? If

        the document creates a new registry, does it define the

        proposed initial contents of the registry and an allocation

        procedure for future registrations? Does it suggest a

        reasonable name for the new registry? See [RFC522 >

        document describes an Expert Review process has Shepherd

        conferred with the Responsible Area Director so that the IESG

        can appoint the needed Expert during the IESG Evaluation?

 

 

The IANA consideration section exists and is inline with the body of the document.

 

  (1.j) Has the Document Shepherd verified that sections of the

        document that are written in a formal language, such as XML

&n sp;   code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

 

No such sections

 

  (1.k) The IESG approval announcement includes a Document

        Announcement Write-Up. Please provide such a Document

        Announcement Write-Up? Recent examples can be found in the

        "Action" announcements for approved documents. The approval

        announcement contains the following section s: matted>     Technical Summary

        Relevant content can frequently be found in the abstract

        and/or introduction of the document. If not, this may be

        an indication that there are deficiencies in the abstract

        or introduction.

     

“This memo describes a Real-time Transport Protocol (RTP) payload

   format for the MIDI (Musical Instrument Digital Interface) command

   language.  The format encodes all commands that may legally appear o bsp; The format is suitable for interactive

   applications (such as network musical performance) and content-

   delivery applications (such as file streaming).  The format may be

   used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss.  Stream behavior, including the

   MIDI rendering method, may be customized during session setup.  The

   format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.”

 

Working Group Summary

       ; & n WG process that is worth noting? For

        example, was there controversy about particular points or

        were there decisions where the consensus was particularly

        rough?

     

The first version of the document came out in 2007 and the document was kept alive in order to capture any errata that will be discovered. The authors now feel that the implementations are stable and that it is time to publish the update.

 

 

 

Document Quality

 &nbs p;  nbsp;Are there existing implementations of the protocol? Have a

        significant number of vendors indicated their plan to

        implement the specification? Are there any reviewers that

        merit special mention as having done a thorough review,

        e.g., one that resulted in important changes or a

        conclusion that the document had no substantive issues? If

        there was a MIB Doctor, Media Type or other expert review,

       & nbsp;wha )? In the case of a Media Type

        review, on what date was the request posted?

 

There are existing implementations and this update for RFC 4695 is based on issues that were found by implementers. 

 

--Boundary_(ID_h3ZT1OjmoFbvuviAr9ohmw)-- From Even.roni@huawei.com Tue Feb 1 11:28:10 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC32B3A6CF1; Tue, 1 Feb 2011 11:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.894 X-Spam-Level: X-Spam-Status: No, score=-103.894 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVFjGJlKs6G6; Tue, 1 Feb 2011 11:27:59 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 650633A6BB2; Tue, 1 Feb 2011 11:27:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFY001P7E7OGQ@szxga04-in.huawei.com>; Wed, 02 Feb 2011 03:31:00 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFY00L6YE7OHW@szxga04-in.huawei.com>; Wed, 02 Feb 2011 03:31:00 +0800 (CST) Received: from windows8d787f9 (bzq-79-182-49-99.red.bezeqint.net [79.182.49.99]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LFY00F20E7CIM@szxml02-in.huawei.com>; Wed, 02 Feb 2011 03:31:00 +0800 (CST) Date: Tue, 01 Feb 2011 21:26:52 +0200 From: Roni Even To: 'Robert Sparks' , iesg-secretary@ietf.org Message-id: <009a01cbc246$01287900$03796b00$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_jp+7alU6oBf6K6r3MxEA4g)" Content-language: en-us Thread-index: AcvCRfjB1pc7AIAlRoSEA+JqZ1mfnA== Cc: payload@ietf.org, draft-ietf-payload-rfc4695-bis.all@tools.ietf.org Subject: [payload] Updated request to publish draft-ietf-payload-rfc4695-bis-00 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Feb 2011 19:28:10 -0000 This is a multi-part message in MIME format. --Boundary_(ID_jp+7alU6oBf6K6r3MxEA4g) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Robert, I would like to update the response to 1.j. I forgot to mention the ABNF defined in Appendix D. The new write up is changed to (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Appendix D define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form. The ABNF was tested using the BAP tool and returned no errors Thanks, Roni Even Document Shepherd Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document went through a Working Group last call and people had enough time to review it. Considering that this document is an update to an existing RFC addressing errata found in implementation the document Shepherd feels that the review was satisfactory. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concerns (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No Concerns (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits?(See the Checklist and idnits ).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? The idnits tool report some comments and one warning which are OK. The document does not change the current media subtype registration so there was no need to review it by . (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. References are split (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA consideration section exists and is inline with the body of the document. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Appendix D define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form. The ABNF was tested using the BAP tool and returned no errors (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. "This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The first version of the document came out in 2007 and the document was kept alive in order to capture any errata that will be discovered. The authors now feel that the implementations are stable and that it is time to publish the update. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? There are existing implementations and this update for RFC 4695 is based on issues that were found by implementers. --Boundary_(ID_jp+7alU6oBf6K6r3MxEA4g) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Robert,

I would like to update the response to 1.j. I forgot to mention the ABNF defined in Appendix D.

The new write up is changed to

 

(1.j) Has the Document Shepherd verified that sections of the

     & nbsp;&nb e written in a formal language, such as XML

        code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

 

Appendix D define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form. The ABNF was tested using the BAP tool and returned no errors

 

 

Roni Even

 

Document Shepherd Write-Up

 

(1.a) Who is the Document Shepherd for this document? Has the

        Document Shepherd personally reviewed this version of the

        document and, in particular, does he or she believe this

        &n forwarding to the IESG for publication?

 

The document shepherd is Roni Even. I have reviewed the document, and believe it is ready for publication.

 

  (1.b) Has the document had adequate review both from key WG members

        and from key non-WG members? Does the Document Shepherd have

        any concerns about the depth or breadth of the reviews that

        have been performed? 

 

The document went through a Working Group last cal ime to review it. Considering that this document is an update to an existing RFC addressing errata found in implementation the document Shepherd feels that the review was satisfactory.

 

  (1.c) Does the Document Shepherd have concerns that the document

        needs more review from a particular or broader perspective,

        e.g., security, operational complexity, someone familiar with

        AAA, internationalization or XML?

 

No concerns

 

 

  (1.d) Does the Docume nt Sheph cerns or

        issues with this document that the Responsible Area Director

        and/or the IESG should be aware of? For example, perhaps he

        or she is uncomfortable with certain parts of the document, or

        has concerns whether there really is a need for it. In any

        event, if the WG has discussed those issues and has indicated

        that it still wishes to advance the document, detail those

        concerns here. Has an IPR di sclosure

        been filed? If so, please include a reference to the

        disclosure and summarize the WG discussion and conclusion on

        this issue.

 

No Concerns

 

(1.e) How solid is the WG consensus behind this document? Does it

        represent the strong concurrence of a few individuals, with

        others being silent, or does the WG as a whole understand and

         ag /p>

 

This is an update to an existing payload specification. It has consensus of a few individual who reviewed the draft.

 

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme

        discontent? If so, please summarise the areas of conflict in

        separate email messages to the Responsible Area Director. (It

        should be in a separate email because this questionnaire is

        entered into the ID Tracker.)

 

No

  (1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits).Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews?

 

The idnits tool report some comments and one warning which are OK.

The document does not change the current media subtype registration so there was no need to review it by .

 

  plit its references into normative and

        informative? Are there normative references to documents that

        are not ready for advancement or are otherwise in an unclear

        state? If such normative references exist, what is the

        strategy for their completion? Are there normative references

        that are downward references, as described in [RFC3967]? If

        so, list these downward references to support the Area

        D irector e for them [RFC3967].

  

 

References are split

 

(1.i) Has the Document Shepherd verified that the document IANA

        consideration section exists and is consistent with the body

        of the document? If the document specifies protocol

        extensions, are reservations requested in appropriate IANA

        registries? Are the IANA registries clearly identified? If

        the document create s a new the

        proposed initial contents of the registry and an allocation

        procedure for future registrations? Does it suggest a

        reasonable name for the new registry? See [RFC5226]. If the

        document describes an Expert Review process has Shepherd

        conferred with the Responsible Area Director so that the IESG

        can appoint the needed Expert during the IESG Evaluation?

 

 

The IANA co s and is inline with the body of the document.

 

 

  (1.j) Has the Document Shepherd verified that sections of the

        document that are written in a formal language, such as XML

        code, BNF rules, MIB definitions, etc., validate correctly in

        an automated checker?

 

Appendix D define the syntax for the RTP MIDI media type parameters in Augmented Backus-Naur Form. The ABNF was tested using the BAP tool and returned no errors

 

  (1.k) The IESG approv al annou nt

        Announcement Write-Up. Please provide such a Document

        Announcement Write-Up? Recent examples can be found in the

        "Action" announcements for approved documents. The approval

        announcement contains the following sections:

     Technical Summary

        Relevant content can frequently be found in the abstract

        and/or introduction of the document. If not, this may be

     &n indication that there are deficiencies in the abstract

        or introduction.

     

“This memo describes a Real-time Transport Protocol (RTP) payload

   format for the MIDI (Musical Instrument Digital Interface) command

   language.  The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable.  The format is suitable for interactive

   applications (such as network musical performance) and content-

   delivery applications (such as file streaming).  The format may be

   used over unicast and multicast UDP and TCP, and it defines tools f or grace loss.  Stream behavior, including the

   MIDI rendering method, may be customized during session setup.  The

   format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio.”

 

Working Group Summary

        Was there anything in WG process that is worth noting? For

        example, was there controversy about particular points or

        were there decisions where the consensus was particularly

     &n bsp;&nbs >

     

The first version of the document came out in 2007 and the document was kept alive in order to capture any errata that will be discovered. The authors now feel that the implementations are stable and that it is time to publish the update.

 

 

 

Document Quality

        Are there existing implementations of the protocol? Have a

        significant number of vendors indicated their plan to

        implement the specification? Are there any reviewers that

   ; & bsp;merit special mention as having done a thorough review,

        e.g., one that resulted in important changes or a

        conclusion that the document had no substantive issues? If

        there was a MIB Doctor, Media Type or other expert review,

        what was its course (briefly)? In the case of a Media Type

        review, on what date was the request posted?

 

There are existing implementations and this update for RFC 4695 is based on issues that were found by implementers. 

  mal> 

--Boundary_(ID_jp+7alU6oBf6K6r3MxEA4g)-- From Internet-Drafts@ietf.org Tue Feb 1 20:00:02 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D642F3A6E88; Tue, 1 Feb 2011 20:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6Ay-7QyrolR; Tue, 1 Feb 2011 20:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D793A6A86; Tue, 1 Feb 2011 20:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110202040001.26146.75454.idtracker@localhost> Date: Tue, 01 Feb 2011 20:00:01 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-avt-rtp-svc-27.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 04:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Scalable Video Coding Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-rtp-svc-27.txt Pages : 105 Date : 2011-02-01 This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others.Table of Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-27.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avt-rtp-svc-27.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-01194514.I-D@ietf.org> --NextPart-- From yekui.wang@huawei.com Wed Feb 2 01:41:57 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C63423A713A for ; Wed, 2 Feb 2011 01:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXA0rzgYr40h for ; Wed, 2 Feb 2011 01:41:56 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id DAF1C3A682E for ; Wed, 2 Feb 2011 01:41:56 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFZ00H1GHRFTD@usaga04-in.huawei.com> for payload@ietf.org; Wed, 02 Feb 2011 03:45:15 -0600 (CST) Received: from dfweml202-edg.china.huawei.com ([172.18.9.108]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LFZ00CG6HREL1@usaga04-in.huawei.com> for payload@ietf.org; Wed, 02 Feb 2011 03:45:15 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Feb 2011 01:45:15 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 02 Feb 2011 01:44:59 -0800 Date: Wed, 02 Feb 2011 09:44:58 +0000 From: Wangyekui In-reply-to: <20110202040001.26146.75454.idtracker@localhost> X-Originating-IP: [10.47.142.199] To: "payload@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [payload] I-D Action:draft-ietf-avt-rtp-svc-27.txt Thread-index: AQHLwo4+HYj4K1r1ikaNAZu4E1/e8ZPt9FaA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110202040001.26146.75454.idtracker@localhost> Cc: "Wei, Xiaohui \(Joanne\)" Subject: Re: [payload] I-D Action:draft-ietf-avt-rtp-svc-27.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 09:41:57 -0000 Compared to -26, this revision includes an improvement to Table 17 and an improvement to the SDP examples, related to AVC/SVC profiles and compatibility flag, thanks to the comments from Xiaohui (Joanne) Wei of Avaya - many thanks! The changes are: - Table 13: Removed "same as: 64 (H), 6E (H10), 7A (H42), or F4 (H44)", twice, for CB and M, and changed "H10I 64" to "H10I 6E" - SDP examples: changed "4d40" to "4de0", such that the base layer can be part of an SVC bitstream of the scalable baseline profile in all SDP examples. BR, YK -----Original Message----- From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, February 01, 2011 11:00 PM To: i-d-announce@ietf.org Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-avt-rtp-svc-27.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for Scalable Video Coding Author(s) : S. Wenger, et al. Filename : draft-ietf-avt-rtp-svc-27.txt Pages : 105 Date : 2011-02-01 This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others.Table of Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-svc-27.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From yekui.wang@huawei.com Wed Feb 2 02:00:34 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D29A3A70CD for ; Wed, 2 Feb 2011 02:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8K2s+neX2vio for ; Wed, 2 Feb 2011 02:00:33 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by core3.amsl.com (Postfix) with ESMTP id 5F9C13A6BAC for ; Wed, 2 Feb 2011 02:00:32 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LFZ00HBQIMFTD@usaga04-in.huawei.com> for payload@ietf.org; Wed, 02 Feb 2011 04:03:51 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.9.107]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LFZ00CLAIMBL1@usaga04-in.huawei.com> for payload@ietf.org; Wed, 02 Feb 2011 04:03:51 -0600 (CST) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Feb 2011 02:03:43 -0800 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 02 Feb 2011 02:03:46 -0800 Date: Wed, 02 Feb 2011 10:03:45 +0000 From: Wangyekui X-Originating-IP: [10.47.142.199] To: "payload@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: Changes to be made to draft-ietf-avt-rtp-rfc3984bis-12.txt Thread-index: AcvCwHpKZZ5cH8S7THmoooz5YrINTQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: Roni Even Subject: [payload] Changes to be made to draft-ietf-avt-rtp-rfc3984bis-12.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 10:00:34 -0000 Dear All, The changes that have been made to Table 17 in draft-ietf-avt-rtp-svc-27.txt should also be made to Table 5 in draft-ietf-avt-rtp-rfc3984bis-12.txt (i.e. to remove "same as: 64 (H), 6E (H10), 7A (H42), or F4 (H44)", twice, for CB and M, and change "H10I 64" to "H10I 6E"). draft-ietf-avt-rtp-rfc3984bis-12.txt has already been approved by IESG as a proposed standard and is now in RFC Editor's queue. We authors therefore plan to make the changes during Author48. ADs, WG chairs and others, please let us know if you have any comments or suggestions. BR, YK From rjsparks@nostrum.com Mon Feb 7 14:10:09 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2353A6F02 for ; Mon, 7 Feb 2011 14:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIwurBXv5DLz for ; Mon, 7 Feb 2011 14:10:08 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 692C23A6EE4 for ; Mon, 7 Feb 2011 14:10:08 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p17MA9kX051713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 7 Feb 2011 16:10:10 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-33-981830027 Date: Mon, 7 Feb 2011 16:10:09 -0600 Message-Id: <2E1EB226-39F8-4367-84F0-BF3F076A06D7@nostrum.com> To: payload@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-payload-rfc4695-bis@tools.ietf.org Subject: [payload] Questions on draft-ietf-payload-rfc4695-bis X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:10:09 -0000 --Apple-Mail-33-981830027 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 1) The 2nd line of the ABNF's production rule for nonzero-for-octet=20 ( / (%x30-33 9(DIGIT))) allows 10 digit strings with a leading 0 - was that intended, or = should this have started %31-33? 2) The following two paragraphs appear in C.6.3 and seem to be redundant = - was it an incomplete edit? The "url" parameter is assigned a double-quoted string representation of a Uniform Resource Locator (URL) for the data object. The string MUST specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or an HTTP over TLS URI (HTTPS, [RFC2818]). The media type/subtype for the data object SHOULD be specified in the appropriate HTTP or HTTPS transport header. The "url" parameter is assigned a double-quoted string representation of a Uniform Resource Locator (URL) for the data object. The string MUST specify a HyperText Transport Protocol URL (HTTP, [RFC2616]). HTTP MAY be used over TCP or MAY be used over a secure network transport, such as the method described in [RFC2818]. The media type/subtype for the data object SHOULD be specified in the appropriate HTTP transport header. --Apple-Mail-33-981830027 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii 1) The 2nd line of the ABNF's production rule for nonzero-for-octet 
     (  / (%x30-33 9(DIGIT)))
allows 10 digit strings with a leading 0 - was that intended, or should this have started %31-33?

2) The following two paragraphs appear in C.6.3 and seem to be redundant - was it an incomplete edit?

The "url" parameter is assigned a double-quoted string representation of
a Uniform Resource Locator (URL) for the data object.  The string MUST
specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or
an HTTP over TLS URI (HTTPS, [RFC2818]).  The media type/subtype for the
data object SHOULD be specified in the appropriate HTTP or HTTPS
transport header.

The "url" parameter is assigned a double-quoted string representation of
a Uniform Resource Locator (URL) for the data object.  The string MUST
specify a HyperText Transport Protocol URL (HTTP, [RFC2616]).  HTTP MAY
be used over TCP or MAY be used over a secure network transport, such as
the method described in [RFC2818].  The media type/subtype for the data
object SHOULD be specified in the appropriate HTTP transport header.

--Apple-Mail-33-981830027-- From john.lazzaro@gmail.com Mon Feb 7 17:10:25 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F7793A6FD3 for ; Mon, 7 Feb 2011 17:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbIIj8Q75App for ; Mon, 7 Feb 2011 17:10:24 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5ED483A6FCE for ; Mon, 7 Feb 2011 17:10:24 -0800 (PST) Received: by bwz12 with SMTP id 12so6157829bwz.31 for ; Mon, 07 Feb 2011 17:10:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bjcA/GP22/cVj5wML/4ikmirghvS/Rt5VuR5OgAy4jU=; b=eGudAAYMYoTPeJ7d4olooRmGd+gx6/8fRcxduZncI0+8qPW/h1Hyn32J4cnZscUyFX 8rhbEBk63HNAHVWQprASM9D2AUbIHPwPkMf4MZdq5rvnu30bxOHhO2xwIgvK8LbGszuL 8GR46KyGWLqEuFdOCG4ctdw4h6PVdNoZSMk0I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=YjTshvKeFBVIUaEuUyqyclD4t565P9xtmTiUmKd2AYjT1j6vn2r7kficLhe12AbVCn JBMuA/QbsgL3A2TMq5oRo76O5M8OH89iOyXYwkucBjLnmvWVqEbIXM2hWH00+3ZH63w3 B5YB+gide6WywiqyR1o9lS+8pfAgx0ls6r/Ro= MIME-Version: 1.0 Received: by 10.204.114.72 with SMTP id d8mr252986bkq.68.1297127428117; Mon, 07 Feb 2011 17:10:28 -0800 (PST) Received: by 10.204.68.205 with HTTP; Mon, 7 Feb 2011 17:10:28 -0800 (PST) In-Reply-To: <2E1EB226-39F8-4367-84F0-BF3F076A06D7@nostrum.com> References: <2E1EB226-39F8-4367-84F0-BF3F076A06D7@nostrum.com> Date: Mon, 7 Feb 2011 17:10:28 -0800 Message-ID: From: John Lazzaro To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-payload-rfc4695-bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] Questions on draft-ietf-payload-rfc4695-bis X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:10:25 -0000 On Mon, Feb 7, 2011 at 2:10 PM, Robert Sparks wrote: > 1) The 2nd line of the ABNF's production rule for nonzero-for-octet > =A0=A0 =A0 (=A0 / (%x30-33 9(DIGIT))) > allows 10 digit strings with a leading 0 - was that intended, or should t= his > have started %31-33? Good catch, this is my error. I'll update the document with a -01.txt. Thanks. > 2) The following two paragraphs appear in C.6.3 and seem to be redundant = - > was it an incomplete edit? Good catch. The second of the two paragraphs appeared in RFC 4695. After the RFC was released, errata came in that requested a clearer wording of the intent, which resulted in the first paragraph. But obviously I forgot to delete the RFC 4695 version. I'll update this with -01.txt als= o. Thanks. Probably will get to submitting -01.txt on Feb 8th in the afternoon PST, will send an email to PAYLOAD once its out. --=20 John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From john.lazzaro@gmail.com Tue Feb 8 13:44:31 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2B83A689E for ; Tue, 8 Feb 2011 13:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLNtKBvcle4H for ; Tue, 8 Feb 2011 13:44:31 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id ACC5E3A689B for ; Tue, 8 Feb 2011 13:44:30 -0800 (PST) Received: by bwz12 with SMTP id 12so308720bwz.31 for ; Tue, 08 Feb 2011 13:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4bXk+l97sSHD4L6F021ZJF0HPIkt3eLKhWlibQlo6G4=; b=S+K1jXW4alLRlmPHzaOVqlQd4RlzmJGzBDqiWoqgzVbKQCrjzMXBBC1cQ3mq/9prxJ mvWwl/+mv3/TxWkehC8IlPjY8gt1f4fJrmjkyB5xF55A1FH5RCkk9bbt/wHJz1kvdBSw 4HRiSKmbHaHdYOKyrcD6d05ehCoPulDTtkO04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FqXzxdYcXbh2jr3KGqV7jmddUGnIBB9QG1RzSfjxbO9wFq+JSjz10TzPbLdnl2SPmv JirtgETvdT9oHcg/Y6P9B8wgimnpNjkGTlzMzCkUyBblpqeg/to+DdiYVjQcklaAnZNi 8RFyEQUDDSeuT2hf8nyaQsJZKFoYBsnUH0BhM= MIME-Version: 1.0 Received: by 10.204.80.82 with SMTP id s18mr2448162bkk.149.1297201477639; Tue, 08 Feb 2011 13:44:37 -0800 (PST) Received: by 10.204.68.205 with HTTP; Tue, 8 Feb 2011 13:44:37 -0800 (PST) In-Reply-To: References: <2E1EB226-39F8-4367-84F0-BF3F076A06D7@nostrum.com> Date: Tue, 8 Feb 2011 13:44:37 -0800 Message-ID: From: John Lazzaro To: Robert Sparks Content-Type: text/plain; charset=ISO-8859-1 Cc: draft-ietf-payload-rfc4695-bis@tools.ietf.org, payload@ietf.org Subject: Re: [payload] Questions on draft-ietf-payload-rfc4695-bis X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:44:32 -0000 On Mon, Feb 7, 2011 at 5:10 PM, John Lazzaro wrote: > Probably will get to submitting -01.txt on Feb 8th in the afternoon PST, > will send an email to PAYLOAD once its out. Done. draft-ietf-payload-rfc4695-bis-01.txt should now be in the IETF repository. This fixes the two issues you found. Thanks again. -- John Lazzaro http://www.cs.berkeley.edu/~lazzaro john [dot] lazzaro [at] gmail [dot] com From Internet-Drafts@ietf.org Tue Feb 8 13:45:02 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B98DE3A67F3; Tue, 8 Feb 2011 13:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id am6Mx5025w7v; Tue, 8 Feb 2011 13:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFCE13A6835; Tue, 8 Feb 2011 13:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208214501.6373.85558.idtracker@localhost> Date: Tue, 08 Feb 2011 13:45:01 -0800 Cc: payload@ietf.org Subject: [payload] I-D Action:draft-ietf-payload-rfc4695-bis-01.txt X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Payloads Working Group of the IETF. Title : RTP Payload Format for MIDI Author(s) : J. Lazzaro, J. Wawrzynek Filename : draft-ietf-payload-rfc4695-bis-01.txt Pages : 171 Date : 2011-02-08 This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-payload-rfc4695-bis-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-payload-rfc4695-bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08134016.I-D@ietf.org> --NextPart-- From iesg-secretary@ietf.org Wed Feb 9 07:36:51 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35F853A6767; Wed, 9 Feb 2011 07:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyB1JXDEQXsb; Wed, 9 Feb 2011 07:36:50 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3EE3A67A2; Wed, 9 Feb 2011 07:36:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209153650.19016.95699.idtracker@localhost> Date: Wed, 09 Feb 2011 07:36:50 -0800 Cc: payload@ietf.org Subject: [payload] Last Call: (RTP Payload Format for MIDI) to Proposed Standard X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 15:36:51 -0000 The IESG has received a request from the Audio/Video Transport Payloads WG (payload) to consider the following document: - 'RTP Payload Format for MIDI' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes a Real-time Transport Protocol (RTP) payload format for the MIDI (Musical Instrument Digital Interface) command language. The format encodes all commands that may legally appear on a MIDI 1.0 DIN cable. The format is suitable for interactive applications (such as network musical performance) and content- delivery applications (such as file streaming). The format may be used over unicast and multicast UDP and TCP, and it defines tools for graceful recovery from packet loss. Stream behavior, including the MIDI rendering method, may be customized during session setup. The format also serves as a mode for the mpeg4-generic format, to support the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds Level 2, and Structured Audio. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Tue Feb 15 06:49:43 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8456D3A6D2E; Tue, 15 Feb 2011 06:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIAPVU7qfVJp; Tue, 15 Feb 2011 06:49:42 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3048B3A6D62; Tue, 15 Feb 2011 06:49:42 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110215144942.32331.1437.idtracker@localhost> Date: Tue, 15 Feb 2011 06:49:42 -0800 Cc: payload chair , Internet Architecture Board , payload mailing list , RFC Editor Subject: [payload] Protocol Action: 'RTP Payload Format for Scalable Video Coding' to Proposed Standard (draft-ietf-avt-rtp-svc-27.txt) X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2011 14:49:43 -0000 The IESG has approved the following document: - 'RTP Payload Format for Scalable Video Coding' (draft-ietf-avt-rtp-svc-27.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Payloads Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avt-rtp-svc/ Technical Summary This memo describes an RTP payload format for Scalable Video Coding (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technically identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP payload format allows for packetization of one or more Network Abstraction Layer (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit in multiple RTP packets. Furthermore, it supports transmission of an SVC stream over a single as well as multiple RTP sessions. The payload format defines a new media subtype name "H264-SVC", but is still backwards compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer, when encapsulated in its own RTP stream, must use the H.264 media subtype name ("H264") and the packetization method specified in [I- D.ietf-avt-rtp-rfc3984bis]. The payload format has wide applicability in videoconferencing, Internet video streaming, and high bit-rate entertainment-quality video, among others. Working Group Summary There was a very heated discussion before the two proposals were merged. Once agreement was achieved the work progress smoothly using a design team. The registration template was posted to ietf-types@iana.org for 2 weeks review: Document Quality This is a payload specification for H.264 scalable video coding. It is being used in some streaming and video conferencing applications. It is referenced by other standard bodies. Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Roni Even is the document shepherd. The responsible area director is Gonzalo Camarillo. From sambasiva.manchili@nexustelecom.com Sat Feb 19 09:10:04 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5C253A6CFB; Sat, 19 Feb 2011 09:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9oq42kOmvPp; Sat, 19 Feb 2011 09:10:04 -0800 (PST) Received: from typhon.nexustelecom.com (typhon.nexustelecom.com [212.203.104.229]) by core3.amsl.com (Postfix) with ESMTP id 5DD3D3A6F7E; Sat, 19 Feb 2011 09:09:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,192,1297033200"; d="scan'208";a="2344874" Received: from unknown (HELO hermes.nexustelecom.com) ([172.29.1.4]) by typhon.nexustelecom.com with ESMTP; 19 Feb 2011 18:10:35 +0100 Received: from hermes.nexustelecom.com (localhost [127.0.0.1]) by hermes.nexustelecom.com (Postfix) with ESMTP id 0ECC3159F64; Sat, 19 Feb 2011 18:10:35 +0100 (CET) Received: from poseidon.nexus-ag.com (unknown [172.29.2.111]) by hermes.nexustelecom.com (Postfix) with ESMTP id 6B6CF159F63; Sat, 19 Feb 2011 18:10:17 +0100 (CET) Received: from poseidon.nexus-ag.com ([172.29.2.111]) by poseidon.nexus-ag.com ([172.29.2.111]) with mapi; Sat, 19 Feb 2011 18:10:17 +0100 From: Sambasiva Rao Manchili To: "tsvwg@ietf.org" , "payload@ietf.org" , "avtcore@ietf.org" , "codec@ietf.org" Date: Sat, 19 Feb 2011 18:07:51 +0100 Thread-Topic: RTP Timestamping in Control messages of IuCS interface. Thread-Index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTg== Message-ID: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TBoneOriginalFrom: Sambasiva Rao Manchili X-TBoneOriginalTo: "tsvwg@ietf.org" , "payload@ietf.org" , "avtcore@ietf.org" , "codec@ietf.org" X-TBoneOriginalCC: Antonio Gambin , Markus Locher , =?iso-8859-1?Q?Ralf_K=FChl?= X-TBoneDomainSigned: false X-Mailman-Approved-At: Sat, 19 Feb 2011 09:33:25 -0800 Cc: Antonio Gambin , =?iso-8859-1?Q?Ralf_K=FChl?= , Markus Locher Subject: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 17:10:05 -0000 Hallo, Can some one in IETF list, please help me to clarify the point w.r.t the Ti= me stamping in RTP header for Audio Stream AMR 5.9. I hope I am addressing to right group. Our implementation of RTP is not accepting the two control messages belongi= ng to the UPP(User plane protocol above RTP) if the two consecutive control= packets arrived has same time stamp with different sequence numbers. The two control messages are UPP_INIT_ACK and Rate Control Message which be= longs to UPP layer on IuCS user plane stack. Our implementation expects the time stamp of second packet to be 320ms grea= ter than the time stamp arrived in 1st Control message of RTP header. Our counter part RTP stack says their implementation is right and can have = the same time stamp in the RTP header of these control messages. RFC 3350 tells about equal timestamps for Video stream belonging to same f= rame, but does not specifically tell about the control messages of its uppe= r layer. We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets from having equal timestamps but rather explicitly allows for it: Several consecutive RTP packets will have equal timestamps if they are (logically) generated at once, e.g., belong to the same video frame. Consecutive RTP packets MAY contain timestamps that are not monotonic if the data is not transmitted in the order it was sampled, as in the case of MPEG interpolated video frames. (The sequence numbers of the packets as transmitted will still be monotonic.) May I kindly ask the RTP experts in Audio Stream area(or specific to IuCS )= can please clarify me. Thank you very much for your time. Best Regads, Samba. This email and any attachment may contain confidential information which is= intended for use only by the addressee(s) named above. If you received thi= s email by mistake, please notify the sender immediately, and delete the em= ail from your system. You are prohibited from copying, disseminating or oth= erwise using the email or any attachment. From Even.roni@huawei.com Sat Feb 19 13:39:01 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA4CD3A6EDF for ; Sat, 19 Feb 2011 13:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.895 X-Spam-Level: X-Spam-Status: No, score=-103.895 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+XMvkk343mp for ; Sat, 19 Feb 2011 13:39:00 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id C47683A6F39 for ; Sat, 19 Feb 2011 13:38:59 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGV00ABMW5QLP@szxga03-in.huawei.com>; Sun, 20 Feb 2011 05:39:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGV00D7NW5QMN@szxga03-in.huawei.com>; Sun, 20 Feb 2011 05:39:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGV00M7HW5GEP@szxml12-in.huawei.com>; Sun, 20 Feb 2011 05:39:26 +0800 (CST) Date: Sat, 19 Feb 2011 23:34:38 +0200 From: Roni Even In-reply-to: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> To: 'Sambasiva Rao Manchili' , payload@ietf.org, avtcore@ietf.org Message-id: <009201cbd07c$d6198570$824c9050$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQ References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> Cc: 'Antonio Gambin' , =?iso-8859-1?Q?'Ralf_K=FChl'?= , 'Markus Locher' Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 21:39:01 -0000 Hi, I am not that familiar with the AMR control message but the general definition for time stamp is the RTP timestamp corresponds to the = sampling instant of the first sample encoded for the first frame-block in the = packet. So if there is no speech information in the second packet it should have = the same timestamp as the previous one. Roni Even > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Sambasiva Rao Manchili > Sent: Saturday, February 19, 2011 7:08 PM > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; codec@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hallo, >=20 > Can some one in IETF list, please help me to clarify the point w.r.t > the Time stamping in RTP header for Audio Stream AMR 5.9. > I hope I am addressing to right group. >=20 > Our implementation of RTP is not accepting the two control messages > belonging to the UPP(User plane protocol above RTP) if the two > consecutive control packets arrived has same time stamp with different > sequence numbers. > The two control messages are UPP_INIT_ACK and Rate Control Message > which belongs to UPP layer on IuCS user plane stack. > Our implementation expects the time stamp of second packet to be 320ms > greater than the time stamp arrived in 1st Control message of RTP > header. >=20 > Our counter part RTP stack says their implementation is right and can > have the same time stamp in the RTP header of these control messages. >=20 > RFC 3350 tells about equal timestamps for Video stream belonging to > same frame, but does not specifically tell about the control messages > of its upper layer. > We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets > from having equal timestamps but rather explicitly allows for it: >=20 > Several consecutive RTP packets will have equal timestamps if > they are (logically) generated at once, e.g., belong to the same > video frame. Consecutive RTP packets MAY contain timestamps = that > are not monotonic if the data is not transmitted in the order it > was sampled, as in the case of MPEG interpolated video frames. > (The sequence numbers of the packets as transmitted will still = be > monotonic.) >=20 > May I kindly ask the RTP experts in Audio Stream area(or specific to > IuCS ) can please clarify me. >=20 > Thank you very much for your time. >=20 > Best Regads, > Samba. >=20 > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from = copying, > disseminating or otherwise using the email or any attachment. >=20 > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload From Even.roni@huawei.com Sun Feb 20 00:20:39 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6FE3A6DA5 for ; Sun, 20 Feb 2011 00:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.595 X-Spam-Level: X-Spam-Status: No, score=-101.595 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XB7rt0HnCMX for ; Sun, 20 Feb 2011 00:20:38 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 231263A6D7B for ; Sun, 20 Feb 2011 00:20:38 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGW00FT3PV6BH@szxga05-in.huawei.com>; Sun, 20 Feb 2011 16:21:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGW00A6UPV53K@szxga05-in.huawei.com>; Sun, 20 Feb 2011 16:21:06 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGW00E41PUXG5@szxml12-in.huawei.com>; Sun, 20 Feb 2011 16:21:05 +0800 (CST) Date: Sun, 20 Feb 2011 10:16:18 +0200 From: Roni Even In-reply-to: <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> To: 'Sambasiva Rao Manchili' , payload@ietf.org, avtcore@ietf.org Message-id: <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4CAABCtEA== References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> <009201cbd07c$d6198570$824c9050$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> Cc: 'Antonio Gambin' , =?iso-8859-1?Q?'Ralf_K=FChl'?= , 'Markus Locher' Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 08:20:39 -0000 Hi, These mailing lists are the right ones for RTP issues. As for your question, the timestamp is the sample timestamp so if there = is no speech in the packet than the time stamp will not progress. For example consider a case where you have an RTP packet with control = and speech data followed by a packet with only control and a packet with = speech and control. If you will advance the timestamp for the control only packet what will = you do with the next one who has the next sampled speech frame. With my limited knowledge of AMR payload, the RTP layer has the table of content which need to know if there is a speech or control frame in the packet, am I wrong?=20 Roni > -----Original Message----- > From: Sambasiva Rao Manchili > [mailto:sambasiva.manchili@nexustelecom.com] > Sent: Sunday, February 20, 2011 9:51 AM > To: Roni Even; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi Roni, > Thank you very much for the writing to me over the weekend. > Yes, the RTP timestamp corresponds to the sampling. In this case it = is > 16 samples per milli second for speech. > It is uncertain for us about the timestmamp of these two consecutive > control messages which are exchanged before real speech transmit on > channel. These are first messages exchanged over RTP. > These both control messages are to be acked before real speech > transmits. Currently we discard one control message as both have same > timestamp and speech will not be transmitted as one control message is > discarded. >=20 > When we capture on wireshark we see difference of 2.5 ms in wireshark > timestamp between these two control packets but RTP header timestamp > remains same but sequence number increases. > If I understood you right as long as there exists no real speech > encoded in the packet then such packets can carry same timestamps. > But then the question comes is it responsibility of RTP to see the > content of bytes belonging to upper layer and decide if this has = speech > or normal control message and then evaluate timestamp of RTP header ? >=20 > Can you please lead me to group who are experts in AMR Iu UP Control > messages (If I had not put the right group in my mailing list)? > Thank you, > Samba. >=20 > ________________________________________ > From: Roni Even [Even.roni@huawei.com] > Sent: Saturday, February 19, 2011 10:34 PM > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi, > I am not that familiar with the AMR control message but the general > definition for time stamp is the RTP timestamp corresponds to the > sampling > instant of the first sample encoded for the first frame-block in the > packet. > So if there is no speech information in the second packet it should > have the > same timestamp as the previous one. >=20 > Roni Even >=20 > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > Behalf Of Sambasiva Rao Manchili > > Sent: Saturday, February 19, 2011 7:08 PM > > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; > codec@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hallo, > > > > Can some one in IETF list, please help me to clarify the point w.r.t > > the Time stamping in RTP header for Audio Stream AMR 5.9. > > I hope I am addressing to right group. > > > > Our implementation of RTP is not accepting the two control messages > > belonging to the UPP(User plane protocol above RTP) if the two > > consecutive control packets arrived has same time stamp with > different > > sequence numbers. > > The two control messages are UPP_INIT_ACK and Rate Control Message > > which belongs to UPP layer on IuCS user plane stack. > > Our implementation expects the time stamp of second packet to be > 320ms > > greater than the time stamp arrived in 1st Control message of RTP > > header. > > > > Our counter part RTP stack says their implementation is right and = can > > have the same time stamp in the RTP header of these control = messages. > > > > RFC 3350 tells about equal timestamps for Video stream belonging to > > same frame, but does not specifically tell about the control = messages > > of its upper layer. > > We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets > > from having equal timestamps but rather explicitly allows for it: > > > > Several consecutive RTP packets will have equal timestamps if > > they are (logically) generated at once, e.g., belong to the > same > > video frame. Consecutive RTP packets MAY contain timestamps > that > > are not monotonic if the data is not transmitted in the order > it > > was sampled, as in the case of MPEG interpolated video frames. > > (The sequence numbers of the packets as transmitted will still > be > > monotonic.) > > > > May I kindly ask the RTP experts in Audio Stream area(or specific to > > IuCS ) can please clarify me. > > > > Thank you very much for your time. > > > > Best Regads, > > Samba. > > > > This email and any attachment may contain confidential information > > which is intended for use only by the addressee(s) named above. If > you > > received this email by mistake, please notify the sender = immediately, > > and delete the email from your system. You are prohibited from > copying, > > disseminating or otherwise using the email or any attachment. > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload >=20 >=20 >=20 > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from = copying, > disseminating or otherwise using the email or any attachment. From sambasiva.manchili@nexustelecom.com Sat Feb 19 23:50:19 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB9BE3A6E07 for ; Sat, 19 Feb 2011 23:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzXjqYSsHtLb for ; Sat, 19 Feb 2011 23:50:17 -0800 (PST) Received: from typhon.nexustelecom.com (typhon.nexustelecom.com [212.203.104.229]) by core3.amsl.com (Postfix) with ESMTP id 95A0A3A6DFF for ; Sat, 19 Feb 2011 23:50:16 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,194,1297033200"; d="scan'208";a="2345249" Received: from unknown (HELO hermes.nexustelecom.com) ([172.29.1.4]) by typhon.nexustelecom.com with ESMTP; 20 Feb 2011 08:50:53 +0100 Received: from hermes.nexustelecom.com (localhost [127.0.0.1]) by hermes.nexustelecom.com (Postfix) with ESMTP id 159CC159F64; Sun, 20 Feb 2011 08:50:53 +0100 (CET) Received: from poseidon.nexus-ag.com (unknown [172.29.2.111]) by hermes.nexustelecom.com (Postfix) with ESMTP id 3A392159F63; Sun, 20 Feb 2011 08:50:38 +0100 (CET) Received: from poseidon.nexus-ag.com ([172.29.2.111]) by poseidon.nexus-ag.com ([172.29.2.111]) with mapi; Sun, 20 Feb 2011 08:50:38 +0100 From: Sambasiva Rao Manchili To: Roni Even , "payload@ietf.org" , "avtcore@ietf.org" Date: Sun, 20 Feb 2011 08:50:37 +0100 Thread-Topic: [payload] RTP Timestamping in Control messages of IuCS interface. Thread-Index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4A= Message-ID: <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com>, <009201cbd07c$d6198570$824c9050$%roni@huawei.com> In-Reply-To: <009201cbd07c$d6198570$824c9050$%roni@huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TBoneOriginalFrom: Sambasiva Rao Manchili X-TBoneOriginalTo: Roni Even , "payload@ietf.org" , "avtcore@ietf.org" X-TBoneOriginalCC: Antonio Gambin , =?iso-8859-1?Q?Ralf_K=FChl?= , Markus Locher X-TBoneDomainSigned: false X-Mailman-Approved-At: Sun, 20 Feb 2011 00:22:48 -0800 Cc: Antonio Gambin , =?iso-8859-1?Q?Ralf_K=FChl?= , Markus Locher Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Feb 2011 07:50:19 -0000 Hi Roni, Thank you very much for the writing to me over the weekend. Yes, the RTP timestamp corresponds to the sampling. In this case it is 16 = samples per milli second for speech. It is uncertain for us about the timestmamp of these two consecutive contro= l messages which are exchanged before real speech transmit on channel. Thes= e are first messages exchanged over RTP. These both control messages are to be acked before real speech transmits. C= urrently we discard one control message as both have same timestamp and spe= ech will not be transmitted as one control message is discarded. When we capture on wireshark we see difference of 2.5 ms in wireshark times= tamp between these two control packets but RTP header timestamp remains sam= e but sequence number increases. If I understood you right as long as there exists no real speech encoded in= the packet then such packets can carry same timestamps. But then the question comes is it responsibility of RTP to see the content = of bytes belonging to upper layer and decide if this has speech or normal c= ontrol message and then evaluate timestamp of RTP header ? Can you please lead me to group who are experts in AMR Iu UP Control messag= es (If I had not put the right group in my mailing list)? Thank you, Samba. ________________________________________ From: Roni Even [Even.roni@huawei.com] Sent: Saturday, February 19, 2011 10:34 PM To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org Cc: Antonio Gambin; Ralf K=FChl; Markus Locher Subject: RE: [payload] RTP Timestamping in Control messages of IuCS interfa= ce. Hi, I am not that familiar with the AMR control message but the general definition for time stamp is the RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet= . So if there is no speech information in the second packet it should have th= e same timestamp as the previous one. Roni Even > -----Original Message----- > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > Behalf Of Sambasiva Rao Manchili > Sent: Saturday, February 19, 2011 7:08 PM > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; codec@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: [payload] RTP Timestamping in Control messages of IuCS > interface. > > Hallo, > > Can some one in IETF list, please help me to clarify the point w.r.t > the Time stamping in RTP header for Audio Stream AMR 5.9. > I hope I am addressing to right group. > > Our implementation of RTP is not accepting the two control messages > belonging to the UPP(User plane protocol above RTP) if the two > consecutive control packets arrived has same time stamp with different > sequence numbers. > The two control messages are UPP_INIT_ACK and Rate Control Message > which belongs to UPP layer on IuCS user plane stack. > Our implementation expects the time stamp of second packet to be 320ms > greater than the time stamp arrived in 1st Control message of RTP > header. > > Our counter part RTP stack says their implementation is right and can > have the same time stamp in the RTP header of these control messages. > > RFC 3350 tells about equal timestamps for Video stream belonging to > same frame, but does not specifically tell about the control messages > of its upper layer. > We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets > from having equal timestamps but rather explicitly allows for it: > > Several consecutive RTP packets will have equal timestamps if > they are (logically) generated at once, e.g., belong to the same > video frame. Consecutive RTP packets MAY contain timestamps that > are not monotonic if the data is not transmitted in the order it > was sampled, as in the case of MPEG interpolated video frames. > (The sequence numbers of the packets as transmitted will still be > monotonic.) > > May I kindly ask the RTP experts in Audio Stream area(or specific to > IuCS ) can please clarify me. > > Thank you very much for your time. > > Best Regads, > Samba. > > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from copying, > disseminating or otherwise using the email or any attachment. > > _______________________________________________ > payload mailing list > payload@ietf.org > https://www.ietf.org/mailman/listinfo/payload This email and any attachment may contain confidential information which is= intended for use only by the addressee(s) named above. If you received thi= s email by mistake, please notify the sender immediately, and delete the em= ail from your system. You are prohibited from copying, disseminating or oth= erwise using the email or any attachment. From sambasiva.manchili@nexustelecom.com Mon Feb 21 03:04:32 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B45C3A7080 for ; Mon, 21 Feb 2011 03:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ck5U1WksCoC for ; Mon, 21 Feb 2011 03:04:31 -0800 (PST) Received: from typhon.nexustelecom.com (typhon.nexustelecom.com [212.203.104.229]) by core3.amsl.com (Postfix) with ESMTP id 51B7C3A706C for ; Mon, 21 Feb 2011 03:04:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,199,1297033200"; d="scan'208";a="2347179" Received: from unknown (HELO hermes.nexustelecom.com) ([172.29.1.4]) by typhon.nexustelecom.com with ESMTP; 21 Feb 2011 12:05:09 +0100 Received: from hermes.nexustelecom.com (localhost [127.0.0.1]) by hermes.nexustelecom.com (Postfix) with ESMTP id 97872159F65; Mon, 21 Feb 2011 12:05:09 +0100 (CET) Received: from poseidon.nexus-ag.com (unknown [172.29.2.111]) by hermes.nexustelecom.com (Postfix) with ESMTP id 6A1CC159F63; Mon, 21 Feb 2011 12:04:51 +0100 (CET) Received: from poseidon.nexus-ag.com ([172.29.2.111]) by poseidon.nexus-ag.com ([172.29.2.111]) with mapi; Mon, 21 Feb 2011 12:04:51 +0100 From: Sambasiva Rao Manchili To: Roni Even , "payload@ietf.org" , "avtcore@ietf.org" Date: Mon, 21 Feb 2011 12:04:49 +0100 Thread-Topic: [payload] RTP Timestamping in Control messages of IuCS interface. Thread-Index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4CAABCtEIABvk5Q Message-ID: <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> <009201cbd07c$d6198570$824c9050$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> In-Reply-To: <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TBoneOriginalFrom: Sambasiva Rao Manchili X-TBoneOriginalTo: Roni Even , "payload@ietf.org" , "avtcore@ietf.org" X-TBoneOriginalCC: Antonio Gambin , =?iso-8859-1?Q?Ralf_K=FChl?= , Markus Locher X-TBoneDomainSigned: false Cc: Antonio Gambin , =?iso-8859-1?Q?Ralf_K=FChl?= , Markus Locher Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 11:04:32 -0000 Hi Roni, Sorry for late reply. Since these are control messages of Upper layer(IuUP Protocol) all the mess= ages from upper layer should be treated same at RTP layer. This as per Laye= red prorotocl architecture princples. To my knowledge RTP layer has no table of contents which differentiates it= as Speech or control frame of upper layer. All messages either Control message or Speech message of Upper layer of RTP= belonging to a paricular subscriber will be sent with same RTP Session nu= mber (Sync Source Identifier) The payload type of RTP may be able to do this, but specification also tell= s in Section 5 of RFC 3550 that "An RTP source MAY change the payload type during a session, but this field= SHOULD NOT be used for multiplexing separate media streams" Here the Payload type we use on IuCS interface for all type of messages is = 96. Thank you, Samba. -----Original Message----- From: Roni Even [mailto:Even.roni@huawei.com] Sent: Sunday, 20. February, 2011 09:16 To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org Cc: Antonio Gambin; Ralf K=FChl; Markus Locher Subject: RE: [payload] RTP Timestamping in Control messages of IuCS interfa= ce. Hi, These mailing lists are the right ones for RTP issues. As for your question, the timestamp is the sample timestamp so if there is = no speech in the packet than the time stamp will not progress. For example consider a case where you have an RTP packet with control and s= peech data followed by a packet with only control and a packet with speech = and control. If you will advance the timestamp for the control only packet what will you= do with the next one who has the next sampled speech frame. With my limited knowledge of AMR payload, the RTP layer has the table of co= ntent which need to know if there is a speech or control frame in the packe= t, am I wrong? Roni > -----Original Message----- > From: Sambasiva Rao Manchili > [mailto:sambasiva.manchili@nexustelecom.com] > Sent: Sunday, February 20, 2011 9:51 AM > To: Roni Even; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. > > Hi Roni, > Thank you very much for the writing to me over the weekend. > Yes, the RTP timestamp corresponds to the sampling. In this case it > is > 16 samples per milli second for speech. > It is uncertain for us about the timestmamp of these two consecutive > control messages which are exchanged before real speech transmit on > channel. These are first messages exchanged over RTP. > These both control messages are to be acked before real speech > transmits. Currently we discard one control message as both have same > timestamp and speech will not be transmitted as one control message is > discarded. > > When we capture on wireshark we see difference of 2.5 ms in wireshark > timestamp between these two control packets but RTP header timestamp > remains same but sequence number increases. > If I understood you right as long as there exists no real speech > encoded in the packet then such packets can carry same timestamps. > But then the question comes is it responsibility of RTP to see the > content of bytes belonging to upper layer and decide if this has > speech or normal control message and then evaluate timestamp of RTP heade= r ? > > Can you please lead me to group who are experts in AMR Iu UP Control > messages (If I had not put the right group in my mailing list)? > Thank you, > Samba. > > ________________________________________ > From: Roni Even [Even.roni@huawei.com] > Sent: Saturday, February 19, 2011 10:34 PM > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. > > Hi, > I am not that familiar with the AMR control message but the general > definition for time stamp is the RTP timestamp corresponds to the > sampling instant of the first sample encoded for the first frame-block > in the packet. > So if there is no speech information in the second packet it should > have the same timestamp as the previous one. > > Roni Even > > > -----Original Message----- > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] On > > Behalf Of Sambasiva Rao Manchili > > Sent: Saturday, February 19, 2011 7:08 PM > > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; > codec@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hallo, > > > > Can some one in IETF list, please help me to clarify the point w.r.t > > the Time stamping in RTP header for Audio Stream AMR 5.9. > > I hope I am addressing to right group. > > > > Our implementation of RTP is not accepting the two control messages > > belonging to the UPP(User plane protocol above RTP) if the two > > consecutive control packets arrived has same time stamp with > different > > sequence numbers. > > The two control messages are UPP_INIT_ACK and Rate Control Message > > which belongs to UPP layer on IuCS user plane stack. > > Our implementation expects the time stamp of second packet to be > 320ms > > greater than the time stamp arrived in 1st Control message of RTP > > header. > > > > Our counter part RTP stack says their implementation is right and > > can have the same time stamp in the RTP header of these control message= s. > > > > RFC 3350 tells about equal timestamps for Video stream belonging to > > same frame, but does not specifically tell about the control > > messages of its upper layer. > > We have read the RFC 3550 , section 5.1 does NOT prevent RTP packets > > from having equal timestamps but rather explicitly allows for it: > > > > Several consecutive RTP packets will have equal timestamps if > > they are (logically) generated at once, e.g., belong to the > same > > video frame. Consecutive RTP packets MAY contain timestamps > that > > are not monotonic if the data is not transmitted in the order > it > > was sampled, as in the case of MPEG interpolated video frames. > > (The sequence numbers of the packets as transmitted will still > be > > monotonic.) > > > > May I kindly ask the RTP experts in Audio Stream area(or specific to > > IuCS ) can please clarify me. > > > > Thank you very much for your time. > > > > Best Regads, > > Samba. > > > > This email and any attachment may contain confidential information > > which is intended for use only by the addressee(s) named above. If > you > > received this email by mistake, please notify the sender > > immediately, and delete the email from your system. You are > > prohibited from > copying, > > disseminating or otherwise using the email or any attachment. > > > > _______________________________________________ > > payload mailing list > > payload@ietf.org > > https://www.ietf.org/mailman/listinfo/payload > > > > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from > copying, disseminating or otherwise using the email or any attachment. This email and any attachment may contain confidential information which is= intended for use only by the addressee(s) named above. If you received thi= s email by mistake, please notify the sender immediately, and delete the em= ail from your system. You are prohibited from copying, disseminating or oth= erwise using the email or any attachment. From Even.roni@huawei.com Mon Feb 21 05:48:56 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9F9B3A6FCF for ; Mon, 21 Feb 2011 05:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=-1.860, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjwu1ued6g3o for ; Mon, 21 Feb 2011 05:48:55 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 3F6493A6FAB for ; Mon, 21 Feb 2011 05:48:55 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGY0039WZQEAM@szxga05-in.huawei.com>; Mon, 21 Feb 2011 21:49:26 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGY00HXCZQDUO@szxga05-in.huawei.com>; Mon, 21 Feb 2011 21:49:26 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGY00HLSZQ3SR@szxml11-in.huawei.com>; Mon, 21 Feb 2011 21:49:25 +0800 (CST) Date: Mon, 21 Feb 2011 15:44:34 +0200 From: Roni Even In-reply-to: <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> To: 'Sambasiva Rao Manchili' , payload@ietf.org, avtcore@ietf.org Message-id: <015001cbd1cd$7eff9110$7cfeb330$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4CAABCtEIABvk5QgAAwv/A= References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> <009201cbd07c$d6198570$824c9050$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> Cc: 'Antonio Gambin' , =?iso-8859-1?Q?'Ralf_K=FChl'?= , 'Markus Locher' Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 13:48:56 -0000 Hi, I am not sure if you read RFC4867 (http://tools.ietf.org/html/rfc4867) = which is the RTP payload specification for AMR Roni Even > -----Original Message----- > From: Sambasiva Rao Manchili > [mailto:sambasiva.manchili@nexustelecom.com] > Sent: Monday, February 21, 2011 1:05 PM > To: Roni Even; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi Roni, > Sorry for late reply. > Since these are control messages of Upper layer(IuUP Protocol) all the > messages from upper layer should be treated same at RTP layer. This as > per Layered prorotocl architecture princples. >=20 > To my knowledge RTP layer has no table of contents which > differentiates it as Speech or control frame of upper layer. > All messages either Control message or Speech message of Upper layer = of > RTP belonging to a paricular subscriber will be sent with same RTP > Session number (Sync Source Identifier) >=20 > The payload type of RTP may be able to do this, but specification also > tells in Section 5 of RFC 3550 that > "An RTP source MAY change the payload type during a session, but this > field SHOULD NOT be used for multiplexing separate media streams" >=20 > Here the Payload type we use on IuCS interface for all type of = messages > is 96. >=20 > Thank you, > Samba. >=20 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Sunday, 20. February, 2011 09:16 > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi, > These mailing lists are the right ones for RTP issues. > As for your question, the timestamp is the sample timestamp so if = there > is no speech in the packet than the time stamp will not progress. > For example consider a case where you have an RTP packet with control > and speech data followed by a packet with only control and a packet > with speech and control. > If you will advance the timestamp for the control only packet what = will > you do with the next one who has the next sampled speech frame. >=20 > With my limited knowledge of AMR payload, the RTP layer has the table > of content which need to know if there is a speech or control frame in > the packet, am I wrong? >=20 > Roni >=20 > > -----Original Message----- > > From: Sambasiva Rao Manchili > > [mailto:sambasiva.manchili@nexustelecom.com] > > Sent: Sunday, February 20, 2011 9:51 AM > > To: Roni Even; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi Roni, > > Thank you very much for the writing to me over the weekend. > > Yes, the RTP timestamp corresponds to the sampling. In this case it > > is > > 16 samples per milli second for speech. > > It is uncertain for us about the timestmamp of these two consecutive > > control messages which are exchanged before real speech transmit on > > channel. These are first messages exchanged over RTP. > > These both control messages are to be acked before real speech > > transmits. Currently we discard one control message as both have = same > > timestamp and speech will not be transmitted as one control message > is > > discarded. > > > > When we capture on wireshark we see difference of 2.5 ms in = wireshark > > timestamp between these two control packets but RTP header timestamp > > remains same but sequence number increases. > > If I understood you right as long as there exists no real speech > > encoded in the packet then such packets can carry same timestamps. > > But then the question comes is it responsibility of RTP to see the > > content of bytes belonging to upper layer and decide if this has > > speech or normal control message and then evaluate timestamp of RTP > header ? > > > > Can you please lead me to group who are experts in AMR Iu UP Control > > messages (If I had not put the right group in my mailing list)? > > Thank you, > > Samba. > > > > ________________________________________ > > From: Roni Even [Even.roni@huawei.com] > > Sent: Saturday, February 19, 2011 10:34 PM > > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi, > > I am not that familiar with the AMR control message but the general > > definition for time stamp is the RTP timestamp corresponds to the > > sampling instant of the first sample encoded for the first frame- > block > > in the packet. > > So if there is no speech information in the second packet it should > > have the same timestamp as the previous one. > > > > Roni Even > > > > > -----Original Message----- > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] = On > > > Behalf Of Sambasiva Rao Manchili > > > Sent: Saturday, February 19, 2011 7:08 PM > > > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; > > codec@ietf.org > > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > > Subject: [payload] RTP Timestamping in Control messages of IuCS > > > interface. > > > > > > Hallo, > > > > > > Can some one in IETF list, please help me to clarify the point > w.r.t > > > the Time stamping in RTP header for Audio Stream AMR 5.9. > > > I hope I am addressing to right group. > > > > > > Our implementation of RTP is not accepting the two control = messages > > > belonging to the UPP(User plane protocol above RTP) if the two > > > consecutive control packets arrived has same time stamp with > > different > > > sequence numbers. > > > The two control messages are UPP_INIT_ACK and Rate Control Message > > > which belongs to UPP layer on IuCS user plane stack. > > > Our implementation expects the time stamp of second packet to be > > 320ms > > > greater than the time stamp arrived in 1st Control message of RTP > > > header. > > > > > > Our counter part RTP stack says their implementation is right and > > > can have the same time stamp in the RTP header of these control > messages. > > > > > > RFC 3350 tells about equal timestamps for Video stream belonging > to > > > same frame, but does not specifically tell about the control > > > messages of its upper layer. > > > We have read the RFC 3550 , section 5.1 does NOT prevent RTP > packets > > > from having equal timestamps but rather explicitly allows for it: > > > > > > Several consecutive RTP packets will have equal timestamps = if > > > they are (logically) generated at once, e.g., belong to the > > same > > > video frame. Consecutive RTP packets MAY contain timestamps > > that > > > are not monotonic if the data is not transmitted in the = order > > it > > > was sampled, as in the case of MPEG interpolated video > frames. > > > (The sequence numbers of the packets as transmitted will > still > > be > > > monotonic.) > > > > > > May I kindly ask the RTP experts in Audio Stream area(or specific > to > > > IuCS ) can please clarify me. > > > > > > Thank you very much for your time. > > > > > > Best Regads, > > > Samba. > > > > > > This email and any attachment may contain confidential information > > > which is intended for use only by the addressee(s) named above. If > > you > > > received this email by mistake, please notify the sender > > > immediately, and delete the email from your system. You are > > > prohibited from > > copying, > > > disseminating or otherwise using the email or any attachment. > > > > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > This email and any attachment may contain confidential information > > which is intended for use only by the addressee(s) named above. If > you > > received this email by mistake, please notify the sender = immediately, > > and delete the email from your system. You are prohibited from > > copying, disseminating or otherwise using the email or any > attachment. >=20 >=20 >=20 >=20 > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from = copying, > disseminating or otherwise using the email or any attachment. From Even.roni@huawei.com Mon Feb 21 06:02:01 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA6B3A6F00; Mon, 21 Feb 2011 06:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKwkV0CQjw2Y; Mon, 21 Feb 2011 06:02:00 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0D3EF3A6EA1; Mon, 21 Feb 2011 06:02:00 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGZ002RI0C3PY@szxga03-in.huawei.com>; Mon, 21 Feb 2011 22:02:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LGZ004FP0C3UK@szxga03-in.huawei.com>; Mon, 21 Feb 2011 22:02:27 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-22-235.red.bezeqint.net [79.178.22.235]) by szxml12-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LGZ0015P0ADVK@szxml12-in.huawei.com>; Mon, 21 Feb 2011 22:02:27 +0800 (CST) Date: Mon, 21 Feb 2011 15:56:41 +0200 From: Roni Even In-reply-to: <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> To: 'Sambasiva Rao Manchili' , payload@ietf.org, 'IETF AVTCore WG' Message-id: <015601cbd1cf$507b89a0$f1729ce0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-us Content-transfer-encoding: quoted-printable Thread-index: AQHL0FeK//SQUrZ5dEaOQI5XewDSTpQJWCmQgACht4CAABCtEIABvk5QgAAwv/A= References: <509DA52866E38F47878413CF102D751F7099C582BD@poseidon.nexus-ag.com> <009201cbd07c$d6198570$824c9050$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C582C0@poseidon.nexus-ag.com> <00b901cbd0d6$78b22270$6a166750$%roni@huawei.com> <509DA52866E38F47878413CF102D751F7099C5CB50@poseidon.nexus-ag.com> Cc: 'Antonio Gambin' , =?iso-8859-1?Q?'Ralf_K=FChl'?= , 'Markus Locher' Subject: Re: [payload] RTP Timestamping in Control messages of IuCS interface. X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 14:02:01 -0000 Hi, I am not sure if you read RFC4867 (http://tools.ietf.org/html/rfc4867) = which is the RTP payload specification for AMR Roni Even > -----Original Message----- > From: Sambasiva Rao Manchili > [mailto:sambasiva.manchili@nexustelecom.com] > Sent: Monday, February 21, 2011 1:05 PM > To: Roni Even; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi Roni, > Sorry for late reply. > Since these are control messages of Upper layer(IuUP Protocol) all the > messages from upper layer should be treated same at RTP layer. This as > per Layered prorotocl architecture princples. >=20 > To my knowledge RTP layer has no table of contents which > differentiates it as Speech or control frame of upper layer. > All messages either Control message or Speech message of Upper layer = of > RTP belonging to a paricular subscriber will be sent with same RTP > Session number (Sync Source Identifier) >=20 > The payload type of RTP may be able to do this, but specification also > tells in Section 5 of RFC 3550 that > "An RTP source MAY change the payload type during a session, but this > field SHOULD NOT be used for multiplexing separate media streams" >=20 > Here the Payload type we use on IuCS interface for all type of = messages > is 96. >=20 > Thank you, > Samba. >=20 > -----Original Message----- > From: Roni Even [mailto:Even.roni@huawei.com] > Sent: Sunday, 20. February, 2011 09:16 > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > interface. >=20 > Hi, > These mailing lists are the right ones for RTP issues. > As for your question, the timestamp is the sample timestamp so if = there > is no speech in the packet than the time stamp will not progress. > For example consider a case where you have an RTP packet with control > and speech data followed by a packet with only control and a packet > with speech and control. > If you will advance the timestamp for the control only packet what = will > you do with the next one who has the next sampled speech frame. >=20 > With my limited knowledge of AMR payload, the RTP layer has the table > of content which need to know if there is a speech or control frame in > the packet, am I wrong? >=20 > Roni >=20 > > -----Original Message----- > > From: Sambasiva Rao Manchili > > [mailto:sambasiva.manchili@nexustelecom.com] > > Sent: Sunday, February 20, 2011 9:51 AM > > To: Roni Even; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi Roni, > > Thank you very much for the writing to me over the weekend. > > Yes, the RTP timestamp corresponds to the sampling. In this case it > > is > > 16 samples per milli second for speech. > > It is uncertain for us about the timestmamp of these two consecutive > > control messages which are exchanged before real speech transmit on > > channel. These are first messages exchanged over RTP. > > These both control messages are to be acked before real speech > > transmits. Currently we discard one control message as both have = same > > timestamp and speech will not be transmitted as one control message > is > > discarded. > > > > When we capture on wireshark we see difference of 2.5 ms in = wireshark > > timestamp between these two control packets but RTP header timestamp > > remains same but sequence number increases. > > If I understood you right as long as there exists no real speech > > encoded in the packet then such packets can carry same timestamps. > > But then the question comes is it responsibility of RTP to see the > > content of bytes belonging to upper layer and decide if this has > > speech or normal control message and then evaluate timestamp of RTP > header ? > > > > Can you please lead me to group who are experts in AMR Iu UP Control > > messages (If I had not put the right group in my mailing list)? > > Thank you, > > Samba. > > > > ________________________________________ > > From: Roni Even [Even.roni@huawei.com] > > Sent: Saturday, February 19, 2011 10:34 PM > > To: Sambasiva Rao Manchili; payload@ietf.org; avtcore@ietf.org > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > Subject: RE: [payload] RTP Timestamping in Control messages of IuCS > > interface. > > > > Hi, > > I am not that familiar with the AMR control message but the general > > definition for time stamp is the RTP timestamp corresponds to the > > sampling instant of the first sample encoded for the first frame- > block > > in the packet. > > So if there is no speech information in the second packet it should > > have the same timestamp as the previous one. > > > > Roni Even > > > > > -----Original Message----- > > > From: payload-bounces@ietf.org [mailto:payload-bounces@ietf.org] = On > > > Behalf Of Sambasiva Rao Manchili > > > Sent: Saturday, February 19, 2011 7:08 PM > > > To: tsvwg@ietf.org; payload@ietf.org; avtcore@ietf.org; > > codec@ietf.org > > > Cc: Antonio Gambin; Ralf K=FChl; Markus Locher > > > Subject: [payload] RTP Timestamping in Control messages of IuCS > > > interface. > > > > > > Hallo, > > > > > > Can some one in IETF list, please help me to clarify the point > w.r.t > > > the Time stamping in RTP header for Audio Stream AMR 5.9. > > > I hope I am addressing to right group. > > > > > > Our implementation of RTP is not accepting the two control = messages > > > belonging to the UPP(User plane protocol above RTP) if the two > > > consecutive control packets arrived has same time stamp with > > different > > > sequence numbers. > > > The two control messages are UPP_INIT_ACK and Rate Control Message > > > which belongs to UPP layer on IuCS user plane stack. > > > Our implementation expects the time stamp of second packet to be > > 320ms > > > greater than the time stamp arrived in 1st Control message of RTP > > > header. > > > > > > Our counter part RTP stack says their implementation is right and > > > can have the same time stamp in the RTP header of these control > messages. > > > > > > RFC 3350 tells about equal timestamps for Video stream belonging > to > > > same frame, but does not specifically tell about the control > > > messages of its upper layer. > > > We have read the RFC 3550 , section 5.1 does NOT prevent RTP > packets > > > from having equal timestamps but rather explicitly allows for it: > > > > > > Several consecutive RTP packets will have equal timestamps = if > > > they are (logically) generated at once, e.g., belong to the > > same > > > video frame. Consecutive RTP packets MAY contain timestamps > > that > > > are not monotonic if the data is not transmitted in the = order > > it > > > was sampled, as in the case of MPEG interpolated video > frames. > > > (The sequence numbers of the packets as transmitted will > still > > be > > > monotonic.) > > > > > > May I kindly ask the RTP experts in Audio Stream area(or specific > to > > > IuCS ) can please clarify me. > > > > > > Thank you very much for your time. > > > > > > Best Regads, > > > Samba. > > > > > > This email and any attachment may contain confidential information > > > which is intended for use only by the addressee(s) named above. If > > you > > > received this email by mistake, please notify the sender > > > immediately, and delete the email from your system. You are > > > prohibited from > > copying, > > > disseminating or otherwise using the email or any attachment. > > > > > > _______________________________________________ > > > payload mailing list > > > payload@ietf.org > > > https://www.ietf.org/mailman/listinfo/payload > > > > > > > > This email and any attachment may contain confidential information > > which is intended for use only by the addressee(s) named above. If > you > > received this email by mistake, please notify the sender = immediately, > > and delete the email from your system. You are prohibited from > > copying, disseminating or otherwise using the email or any > attachment. >=20 >=20 >=20 >=20 > This email and any attachment may contain confidential information > which is intended for use only by the addressee(s) named above. If you > received this email by mistake, please notify the sender immediately, > and delete the email from your system. You are prohibited from = copying, > disseminating or otherwise using the email or any attachment. From Even.roni@huawei.com Thu Feb 24 15:18:49 2011 Return-Path: X-Original-To: payload@core3.amsl.com Delivered-To: payload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79E713A680C; Thu, 24 Feb 2011 15:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.209 X-Spam-Level: X-Spam-Status: No, score=-103.209 tagged_above=-999 required=5 tests=[AWL=1.285, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxDyprOd8Uyk; Thu, 24 Feb 2011 15:18:48 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 546123A6808; Thu, 24 Feb 2011 15:18:48 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH5001ZBA4GA7@szxga03-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LH5009GVA4GL4@szxga03-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Received: from windows8d787f9 (bzq-79-178-14-23.red.bezeqint.net [79.178.14.23]) by szxml11-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LH50046VA453C@szxml11-in.huawei.com>; Fri, 25 Feb 2011 07:19:28 +0800 (CST) Date: Fri, 25 Feb 2011 01:19:25 +0200 From: Roni Even To: 'IETF AVTCore WG' Message-id: <004d01cbd479$4e307140$ea9153c0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw)" Content-language: en-us Thread-index: AcvUeUbQYcW+WCcvRUa1Q6RXKYvdgw== Cc: payload@ietf.org, xrblock@ietf.org Subject: [payload] Requests for agenda time in Prague IETF80 X-BeenThere: payload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Audio/Video Transport Payloads working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 23:18:49 -0000 This is a multi-part message in MIME format. --Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, This will be the first meeting after the restructuring of AVT. We will have one time slot for AVTCore and we will use this timeslot also to present the status of the new payload and xrblock working groups. If you wish to have agenda time at the upcoming meeting in Prague , please send an agenda request to the chairs. We are trying to prepare the agenda early and not wait for the last minute. We will use the time for presentations giving priority based on the AVTCore milestones and open issues. The draft agenda shows that AVTCore will meet on Monday 13:00 -15:00 in Roma room. Note that this is not the final agenda. Thanks Magnus Westerlund and Roni Even AVTCore Chairs. Ali Begen and Roni Even Payload Chairs Peter Musgrave and Roni Even XRblock Chairs. --Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi,

This will be the first meeting after the restructuring of AVT. We will have one time slot for AVTCore and we will use this timeslot also to present the status of the new payload and xrblock working groups.

 

If you wish to have agenda time at the upcoming meeting in Prague , please send an agenda request to the chairs. We are trying to prepare the agenda early and no t wait f /o:p>

 

 

We will use the time for presentations giving priority based on the AVTCore milestones and open issues.

 

 

The draft agenda shows that AVTCore will meet on Monday 13:00 -15:00 i n Roma r t the final agenda.

 

Thanks
Magnus Westerlund and Roni Even AVTCore Chairs.
 
Ali Begen and Roni Even Payload Chairs
 
Peter Musgrave and Roni Even XRblock Chairs.

 

--Boundary_(ID_+tffHAXqK6M1PNbt/YaUvw)--