Subject: RE: [MMUSIC] draft-ietf-mmusic-media-loopback-05

From: "Hedayat, Kaynam" <[email-masked]>
Date: Mon, 15 Jan 2007 09:02:17 -0500

Hi Satish,

Thank you for the comments. My comments below.

Regards,
Kaynam 

> -----Original Message-----
> From: Mundra, Satish [mailto:[email-masked]] 
> Sent: Sunday, January 07, 2007 5:22 PM
> To: Hedayat, Kaynam
> Cc: MMUSIC WG
> Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05
> 
> Hi Kaynam,
> 
> I have following comments on this draft.
> 
> 1. I am not sure if "rtp-start-loopback" mode defined in 
> section5.2 is necessary. One can always start a session in 
> normal media processing mode and then change the mode to 
> loopback as mentioned in section 5.6 of the draft.  The 
> "rtp-start-loopback" seems to be accomplishing the same by 
> avoiding additional OFFER/ANSWER exchange which will be 
> needed to move the session to loopback mode in absence of 
> rtp-start-loopback.  
This adds the flexibility to start the call with loopback (something
that is needed in performance management systems). And with additional
OFFER/ANSWER, the requirement to traverse NAT's does not change. The new
OFFER/ANSWER can potentially have completely different ports.
> 
> 2. The draft specifies the rules analogous to RFC3264 for the 
> media formats <fmt> signaled via the a=<loopback-mode>=:<fmt> 
> line in SDP. IMO, the OFFER/ANSWER rules specified in RFC3264 
> are more than sufficient to accomplish the desired 
> loopback-mirror(OFFERER) and
> loopback-source(ANSWERER) behavior
> when the "fmt" are signaled via the m= line.
With source and mirror attributes it is possible for the OFFERER to be
mirror (and vice versa).
> 
> 3. I also don't see the need for the attributes 
> "rtp-pkt-loopback" and "rtp-media-loopback". 
> The payload formats "audio/encaprtp" and "audio/rtploopback" 
> are meaningful only when the loopback-mode is mode is 
> "rtp-pkt-loopback".  If "loopback" attribute is present in 
> answer but answerer chooses to send payload other than one 
> signaled for "encaprtp"  or "rtploopback", then it is implied 
> that the mode is rtp-media-loopback. For consistency, I think 
> it's desirable to define audio/medialoopback" for the above 
> mode. This would allow the selection or negotiation of the 
> appropriate loopback mode preferences using the payload types 
> on the m-line following the OFFER/ANSWER rules and would 
> simplify the implementation. 
In cases where only media loopback is desired this is needed.
> 
> 4. I think the draft needs to includes Media Type 
> registration for the RTP payload formats "audio/encaprtp" 
> and "audio/rtploopback" that are introduced.
I will look into it.
> Regards,
> Satish Mundra 

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