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

From: "Venna, Nagarjuna" <[email-masked]>
Date: Wed, 30 Jul 2008 11:46:41 -0400

Resending this to the list after getting on the whitelist.
 
Thanks,
Nagarjuna

________________________________

From: Venna, Nagarjuna 
Sent: Tuesday, July 15, 2008 2:14 PM
To: 'Diego Costantini'; [email-masked]
Subject: RE: [MMUSIC] Question about draft-ietf-mmusic-media-loopback-08

Diego, 
 
Sorry for the delay in replying to your questions. My answers are
inline.
 
Thanks,
Nagarjuna
 
________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Diego Costantini
Sent: Tuesday, June 10, 2008 4:50 AM
To: Diego Costantini; [email-masked]
Subject: Re: [MMUSIC] Question about draft-ietf-mmusic-media-loopback-08

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.
[Venna, Nagarjuna] For RTP/AVP, no payload type is specified and SDP is
used to signal this dynamically. I believe the language is standard
leaving it vague for any other profiles. 

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?
[Venna, Nagarjuna] It was left out to keep the example smaller. It was
felt that the rtpmap line did not add any value to the case being
discussed there, so it was left out. If you feel it is confusing, we can
add it back. 

3)  ...MUST be based...

"The RTP timestamp MUST based on the same clock used by the
loopback-source."
[Venna, Nagarjuna] Will fix. 

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."
[Venna, Nagarjuna] It specifies that the receive timestamp field should
be computed based on when the last octet of the packet is received at
the mirror. 

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)
[Venna, Nagarjuna] That is right. 

6)  I would use different ports for request and response in the
examples, using the same could be confusing since it rarely happens.
[Venna, Nagarjuna] I will do that. 

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