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

From: "Hedayat, Kaynam" <[email-masked]>
Date: Thu, 7 Oct 2004 17:00:50 -0400

Paul,

Thank you for your comments. Please see my reply below.

Regards,
Kaynam

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, October 05, 2004 3:50 PM
To: Hedayat, Kaynam
Cc: [email-masked]'
Subject: Re: [Sipping] New internet draft on media loopback

I support the functionality represented by this draft. A few comments:

- this seems to be structured for consideration as a draft in the
   SIP WG. But the content is all about SDP and offer/answer. As such,
   I think it makes more sense to target this to the MMUSIC WG. This
   would mean removing anything specific to SIP - which should be easy
   because there is little or nothing here that needs to be specific
   to SIP.

   A companion draft in the SIP (or SIPPING) WG could be developed to
   specify sip specific usage rules and guidelines.

[KH] I agree with your comments. We will separate the draft into two drafts,
one addressing sdp issues and one sip usage issues.

- Section 6.3 says "The loopback-source attribute can only appear in an
   offer", and 6.4 says "The loopback-mirror attribute can only appear in
   an answer". There seems no reason for this restriction. All that is
   required is that a loopback-source offer be answered by a
   loopback-mirror and visa versa. Perhaps it is more likely that the
   source be offered and the mirror answered, but the opposite clearly
   has meaning. (I.e. please test me.) Of course it may be harder for a
   testee to find a tester than the converse, but that is a usage issue.

   Note also that section 6.5 mentions "In cases where the offer contains
   the loopback-mirror attribute", implying that support for this has
   been considered.

[KH] Per Arjun's comments we didn't see any reason for this restriction
and will remove it from the draft. The only restriction will be that
the answer should be the opposite of the offer.

- section 6.5 (typo): "one code" should be "one codec".
[KH] Corrected.

- 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.

- section 11 says: "...given that it is recommended that the user is not
   alerted for calls that only have loopback media modes..." but I can
   find no such recommendation. I think this would relate back to the
   partitioning of mmusic and sip aspects into separate drafts. Alerting
   is a sip consideration.

[KH]Section 10.2 specifies,
"Furthermore, it is RECOMMENDED that the user is not alerted for 
    calls that only have loopback media modes and when such calls are 
    answered automatically."

	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: Thu, 07 Oct 2004 17:53:08 -0400

> 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