Subject: RE: [Sipping] New internet draft on media loopback

From: "Hedayat, Kaynam" <[email-masked]>
Date: Fri, 8 Oct 2004 12:03:23 -0400

Paul,

I see your point. The notations allows for response of both loopback modes
(in case of OPTIONS request). One option would be:

a=loopback:rtp-media-loopback rtp-pkt-loopback
a=loopback-mirror loopback-source

The loopback types apply to loopback-mirror only.

Regards,
Kaynam

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Thursday, October 07, 2004 5:53 PM
To: Hedayat, Kaynam
Cc: [email-masked]'
Subject: Re: [Sipping] New internet draft on media loopback

Hedayat, Kaynam wrote:
> Paul,
> 
> Thank you for your comments. Please see my reply below.
>

Just one further response:

> - section 9.4: is there a way to indicate support for both loopback
>    types, and/or for both loopback-source and loopback-mirror? It would
>    be a good thing to do. I think it should be possible to tweak things
>    so it is.
> 
> [KH] I don't see any reason for specifying loopback-source in the
> answer in this case. The point is to query a device to mirror a
> stream. The case for querying a device to source a loopback stream
> should be addressed at a higher level.

I don't follow you. This is just a continuation of the symetry of the 
two modes. If I can send an offer with loopback-mirror and get a 
response of loopback-source, then it would be good to support an OPTIONS 
query where I can determine that a device actually supports that mode of 
operation.

Of course there will be higher level functions for deciding which nodes 
to query, but that doesn't negate the value of this basic level.

I just see this as a small effort of structuring the notation so that it 
MAY be used in this way. I can imagine that there could be testing nodes 
that would be capable of operating in either mode. It would be good for 
them to be able to indicate this capability.

	Paul

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Oct 2004 12:54:42 -0400

> a=loopback:rtp-media-loopback rtp-pkt-loopback

That works for me - both in OPTIONS and in an offer. (Means the answerer 
mush choose one.)

> a=loopback-mirror loopback-source

Trouble is this is inconsistent with the other "direction" attributes. 
E.g. I can't say:

   a=send recv

If these are to be considered as alternatives to 
send/recv/sendrecv/inactive, then I think consistent conventions should 
apply. Going that way would suggest adding yet another attribute, 
perhaps loopback-source-mirror or loopback-either. That doesn't seem 
very appealing.

Another possibility is to decouple these attributes from the 
directionality, and just mandate that when using them you must also 
negotiate sendrecv. If you did that, then what you suggest above would 
be fine.

> The loopback types apply to loopback-mirror only.

Why? They are equally applicable to loopback-source. If I am a mirror 
looking for a source then I may also be looking for a source that can 
provide the kind of test I am capable of cooperating with, or that I 
would like to have performed.

	Paul