Subject: [MMUSIC] Comments on draft-ietf-mmusic-media-loopback-09.txt

From: "Mundra, Satish" <[email-masked]>
Date: Fri, 12 Sep 2008 14:04:12 -0500

Some comments on this draft: 

1) In section 5.1 on page 6: "The loopback-source is able to filter rtp-start-loopback packets 
             from other types of loopback with the payload type of the packet."

      If the loopback type is rtp-media-loopback then the loopback packets and rtp-start-loopback
      packets are likely to have the same payload type and can not be filtered on 
     the basis of payload type. This is evident from the answer example provided in section 10.5 where 
      both the rtp-start-loopback and rtp-media-loopback have payload type of "0". 

      It's not also clear if loopback source can negotiate media stream with CN(13) or TELEPHONE-EVENT for 
      various types of loopback. If it's permissible then even in case of rtp-pkt-loopback (audio/rtploopback) a
      source will not be able to filter CN, TELEHONE-EVENT from the audio packets on the basis of payload type. 

2) In Section 5.1, page 6: "The media port number for rtp-start-loopback MUST be the same as the corresponding 
    loopback attribute that will take over after the reception of first media packet from the 
    offering entity."

    This statement is confusing, I think this requirement is clearly defined in RFC4961 Symmetric 
    RTP/RTCP and should be referred to instead. 

3) In section 5.2, page7: "The RTP payload types indicated in the a=loopback-source line are
   the payload types for the codecs the offerer is willing to send."

   All examples in draft use static payload types on a=loopback-source line. There is no requirement 
   in the draft that requires that the payload types appearing on the a=loopback-source 
   line MUST be preset on the m= line. 
   It's not clear how dynamic payload types that are specified on the a=loopback-source line get mapped 
   to encoding method.  I think some example using dynamic payload types will help clarify this. 

4)  In section 7.1.1 Page11: "Marker (M) bit: If the received RTP packet is looped back in 
    multiple RTP packets, the M bit is set to 1 in the last packet, 
    otherwise it is set to 0." 

    The payload header defined in section 7.1.2 defines the fragmentation bits (First 
    Fragment (00) /Last Fragment (01) /No Fragmentation(10)/ Intermediate Fragment (11).).
    It seems unnecessary to define the new behavior for this bit in the header. 

5) In section 7.1.2 Page 12:  "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." 

    It's not clear if the last octet referred here is the last octet in each fragmented 
    packet or the last octet of the received packet. Rewording this would be helpful.  
    One would expect that all the fragmented packets would not only have same RTP timestamp but 
    also the same Receive timestamp (see section 5.1 RFC 3550). 

    Typo in Receieve above. 

6) In section 7.1.1 : "Sequence Number: The RTP sequence number SHOULD be generated by the 
   loopback-mirror in the usual manner with a constant random offset."

   For some RTP header fields the draft uses the language "set as described in RFC 3550 [RFC3550]". 
   Are the header fields that are defined in this draft in a different language without referring 
   to RFC3550 deviate from the definition in RFC3550 ? 

7)  In section 7.1.1 : "Timestamp: The RTP timestamp denotes the sampling instant for when 
    the loopback-mirror is transmitting this packet to the loopback-
    source.  The RTP timestamp MUST be based on the same clock used by 
    the loopback-source. The initial value of the timestamp SHOULD be 
    random for security reasons (see Section 5.1 of RFC 3550 
    [RFC3550])."

    How does the mirror base his time stamp on the clock used by the loopback source ?
 
8) Typo in Section 5.2 on page6 "The format descrption"

Regards,

Satish Mundra

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