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

From: "Mundra, Satish" <[email-masked]>
Date: Sun, 7 Jan 2007 16:21:53 -0600

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.  

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.

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. 

4. I think the draft needs to includes Media Type registration for the
RTP payload formats "audio/encaprtp" 
and "audio/rtploopback" that are introduced.

Regards,

Satish Mundra 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 10:51:12 -0500

> session to loopback mode in absence of 

There is some value in knowing from the beginning that the session is 
for the purpose of loopback. In that case the UAS may consider it 
acceptable to auto-answer the call, where otherwise it would not.

Also, if you start out with a regular media session and then switch to a 
loopback session it is a little more difficult to synchronize the 
loopback processing. The UAS needs to figure out which is the first 
packet that should be looped back rather than rendered, and similarly 
for the UAC. Not an insurmountable problem, but an added complexity.

	Paul

---

From: "Mundra, Satish" <[email-masked]>
Date: Mon, 8 Jan 2007 13:07:33 -0600

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, January 08, 2007 10:51 AM
> To: Mundra, Satish
> Cc: Hedayat, Kaynam; MMUSIC WG
> Subject: Re: [MMUSIC] draft-ietf-mmusic-media-loopback-05
> 
> 
> 
> Mundra, Satish wrote:
> > Hi Kaynam,
> > 
> > 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.
> 
> There is some value in knowing from the beginning that the 
> session is for the purpose of loopback. In that case the UAS 
> may consider it acceptable to auto-answer the call, where 
> otherwise it would not.
> 

UAS probably would also have to ensure that user is not alerted for
these calls apart from auto answering 
so there will have to be some means of signaling this intent (may be
Alert-Info in case of SIP). 
If the SDP attribute is to be used for this purpose then the loopback
payloads can be present on the media 
line but not as preferred to allow the call to start in normal mode of
media processing. 

> Also, if you start out with a regular media session and then 
> switch to a loopback session it is a little more difficult to 
> synchronize the loopback processing. The UAS needs to figure 
> out which is the first packet that should be looped back 
> rather than rendered, and similarly for the UAC. Not an 
> insurmountable problem, but an added complexity.
> 

Since the transition between different loopback modes (including  the
loopback-none to begin with) will happen 
with re-invite (new RTP session), there should be no confusion for the
UAS as to when to begin the loopback.

--Satish

> > formats <fmt> signaled via the a=<loopback-mode>=:<fmt> 
> line in SDP. 
> > IMO, the OFFER/ANSWER rules specified in RFC3264 are more than 
> > 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.
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 08 Jan 2007 16:14:33 -0500

> line but not as preferred to allow the call to start in normal mode of

The difference is that if the call starts out normally, then the media 
sent must come from someplace. Typically it would come from the 
microphone of the device. This is not something you would typically want 
if you are going to auto-answer a call - it turns the phone into a 
surveillance device.

The usage of this mechanism for unattended testing of devices requires a 
variety of pieces. Not alerting is another part of that. There is some 
controversy (justified) about that, which is, I think, a reason it isn't 
mentioned in this draft.

> UAS as to when to begin the loopback.

I guess it could be clear if the new session chose a different address 
or port. If the address and port remain the same, then its still a bit 
tricky.

	Paul

---

From: "Mundra, Satish" <[email-masked]>
Date: Mon, 8 Jan 2007 18:00:44 -0600

> Sent: Monday, January 08, 2007 4:15 PM
> To: Mundra, Satish
> session is 
> > these calls apart from auto answering so there will have to be some 
> > means of signaling this intent (may be Alert-Info in case of SIP).
> > payloads can be present on the media line but not as preferred to 
> > allow the call to start in normal mode of media processing.
> 
> The difference is that if the call starts out normally, then 
> the media sent must come from someplace. Typically it would 
> come from the microphone of the device. This is not something 
> you would typically want if you are going to auto-answer a 
> call - it turns the phone into a surveillance device.
> 

This behavior is possible even if you were to signal rtp-start-loopback,

draft at present requires transmission of the media by mirror until it
receives 
media from the source so if a source desires then it can convert such a
phone 
to surveillance device by not sending any media. If the call is for the
purpose of loopback then
the loopback attribute would be required in SDP for the reasons you
mention, I am only proposing that 
loopback-types including the rtp-start-loopback are unnecessary(comment
2,3 below) 
and would simplify this draft and implementation. 

I guess a guidance is required in the draft that that any media sent for
calls established using the 
procedures specified in this draft should not come from any real source.

--Satish

> The usage of this mechanism for unattended testing of devices 
> requires a variety of pieces. Not alerting is another part of 
> that. There is some controversy (justified) about that, which 
> is, I think, a reason it isn't mentioned in this draft.
> 
> >> Also, if you start out with a regular media session and 
> then switch 
> >> to a loopback session it is a little more difficult to synchronize 
> >> the loopback processing. The UAS needs to figure out which is the 
> >> first packet that should be looped back rather than rendered, and 
> >> similarly for the UAC. Not an insurmountable problem, but an added 
> >> complexity.
> >>
> > 
> > loopback-none to begin with) will happen with re-invite (new RTP 
> > session), there should be no confusion for the UAS as to 
> when to begin 
> > the loopback.
> 
> I guess it could be clear if the new session chose a 
> different address or port. If the address and port remain the 
> same, then its still a bit tricky.
> 
> 	Paul
> 
> > --Satish
> > 
> > 
> >> 	Paul
> >>