Subject: Re: [MMUSIC] Question about draft-ietf-mmusic-media-loopback-08

From: "Diego Costantini" <[email-masked]>
Date: Tue, 10 Jun 2008 10:49:30 +0200

Is this draft proceeding any further?

I would really appreciate it to be standardized since I am going to use such extension for monitoring purposes, but I noticed no answers to Colin's arguments and my questions (which I repropose with some more).

1)  I read:

"7.1.1-2 Usage of RTP Header fields

    Payload Type (PT): The assignment of an RTP payload type for this 

    packet format is outside the scope of this document; it is either 

    specified by the RTP profile under which this payload format is 

    used or more likely signaled dynamically out-of-band (e.g., using 

    SDP; section 7.3 defines the name binding)..."

(The last referenced section is not 7.3 but 7.1.3 (and 7.2.3))

"7.1.3 Usage of SDP

    The payload type number for the encapsulated stream can be 

    negotiated using a mechanism like SDP. There is no static payload 

    type assignment for the encapsulated stream, so dynamic payload 

    type numbers MUST be used.  The binding to the name is indicated by 

    an rtpmap attribute.  The name used in this binding is "encaprtp"."

Since dynamic payload MUST be used, then mentioning in 7.1.1 that it can be specified by the RTP profile could be misleading.

2)  In the offer of the second example in section 5.4 there isn't rtpmap for 112 with encaprtp/rtploopback. Isn't it mandatory in presence of the optional rtp-pkt-loopback type? Maybe what is mandatory is the "use" of them, while the request SHOULD include an rtpmap?

3)  ...MUST be based...

"The RTP timestamp MUST based on the same clock used by the loopback-source."

4)  There is one typo and I am not sure of the meaning of this sentence:

"The Receieve timestamp denotes the sampling instant for when the 

    last octet of the media packet that is being encapsulated by the 

    loopback-mirror is received from the loopback-source."

5)  Here:

5.1 Loopback Type Attribute

    "The loopback-source is 

    able to filter rtp-start-loopback packets from other types of 

    loopback with the payload type of the packet"

How? By analysing the payload type (PT) from the RTP header? (negotiated in advance for rtp-start-loopback and rtp-media-loopback/rtp-pkt-loopback)

6)  I would use different ports for request and response in the examples, using the same could be confusing since it rarely happens.

Thank you,

Diego

=============================

Diego Costantini

NEC Europe Ltd.

NEC Laboratories Europe

Network Research Division

Kurfuersten-Anlage 36

69115 Heidelberg

Germany

[email-masked]

http://www.nw.neclab.eu

=============================

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic