Subject: [Sipping] New internet draft on media loopback

From: "Hedayat, Kaynam" <[email-masked]>
Date: Mon, 4 Oct 2004 03:22:26 -0400

I would like to bring the attention of the group to a new internet draft on
media loopback capability in SIP sessions. The draft can be found at
http://www.ietf.org/internet-drafts/draft-hedayat-media-loopback-00.txt

Regards,
Kaynam

-----------------------------------------
Kaynam Hedayat
Chief Technology Officer
Brix Networks
285 Mill Road
Chelmsford, MA 01824

tel.   978.367.5611
fax.   978.367.5700
[email-masked]
www.brixnet.com

See it before they hear it: Test the performance and quality of your VoIP at
www.TestYourVoip.com

_______________________________________________
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: Tue, 05 Oct 2004 15:49:50 -0400

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.

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

- section 6.5 (typo): "one code" should be "one codec".

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

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

	Paul

---

From: Arjun Roychowdhury <[email-masked]>
Date: Tue, 5 Oct 2004 19:44:32 -0400

>   because there is little or nothing here that needs to be specific

I like the partitioning idea. One of the ideas that we discussed was
to _possibly_ later develop another draft that would be related to
identification of "test" calls in general and have this media draft
refer the "test" draft, since media-loopback is essentially a
specialized test scenario.
Speaking for myself, I like the idea of completely disassociating the
current draft from SIP and developing the additional SIP draft with
guidelines and possibly the other ideas described above.

I think Kaynam has already posted this across to mmusic in the
meantime. Do we need to remove all references to SIP for this draft to
be considered in mmusic ?

>   the loopback-mirror attribute", implying that support for this has

Oops - I think was a remnant of an earlier internal debate we had
where one of the older versions of the draft had the ability to switch
source and mirror only in cases of reINVITEs coming from the reverse
side (example A invites B, then B decides to re-INVITE to extend the
session, the B sends mirror in the offer to keep the flow of testing
intact - anyway we discarded that idea as leading to complexity).

Specific to your note on allowing mirror in the offer, I don't beleive
there is any technical reason not to allow it, but just that I am not
sure how common a 'please test me' requirement is.

>   be a good thing to do. I think it should be possible to tweak things

Yes - I think it should be possible for a UA to return both back. I
would think this makes sense especially if the other authors also
believe allowing a 'mirror' in the offer is a good idea.

>   partitioning of mmusic and sip aspects into separate drafts. Alerting

The reccomendation is part of 10.2 UAS guidelines

regds
arjun
-- 
Arjun Roychowdhury

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Oct 2004 10:51:03 -0400

> be considered in mmusic ?

I defer to those more familiar with procedures in mmusic. But I think
they don't all have to be removed, but should be relegated to examples,
while leaving open the possibility that some other protocol might use
this. Essentially this is just an extension to RFC3264, so that would
probably be a good guideline to follow.

 > sure how common a 'please test me' requirement is.

It seems less likely. But why gratuitously exclude it when there is no
technical reason to do so?

 > believe allowing a 'mirror' in the offer is a good idea.

The trick here is that as things are currently structured, it would not
make sense to include both in an offer or answer. Yet the SDP returned
in response to an OPTIONS is supposed to be like what the UA would offer.

To fix this it may be necessary to actually allow the offering of both.
We can find current examples of how to do this that can be followed:

- for the loopback attribute, the strategy used for codecs in the m-line
    could be used - offer all that are supported, with the answerer
    picking. E.g.:

	offer:  a=loopback:rtp-pkt-loopback rtp-media-loopback
	answer: a=loopback:rtp-media-loopback

- for loopback-source/loopback-mirror, the strategy used for
    send/recv/sendrecv - add another value that means 'both', such
    as source-or-mirror. E.g.

	offer:  a=loopback-source-or-mirror
	answer: a=loopback-source

    This is a little ugly, but it needs to be understood as added
    alternatives to
               send/recv/sendrecv/inactive

    An alternative might be to divorce it from that family of
    directionality attributes. Make it a separate attribute to be
    used in conjunction with sendrecv. Something like:

	Offer:  a=sendrecv
	        a=loopback-role: source mirror

	answer: a=sendrecv
	        a=loopback-role: mirror

 > The reccomendation is part of 10.2 UAS guidelines

Sorry - I looked but still missed it.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Oct 2004 19:02:58 -0400

Thanks for writing this up.

I like the general idea of adding mechanisms in sip to facilitate 
testing and monitoring of an active network, but there are a lot of 
higher level questions about this specific proposal.

Firstly, I think you need to step back and really understand the problem 
that is being solved. Is the problem that you want a way to have network 
operator that deploys sip figure out the quality of calls made in the 
network? Is the problem that someone in the field wants to test if the 
system is "working"? That is, if a call can be made?

I'm assuming it's probably the latter. Do you need the phone that is 
acting as the mirror to also automatically answer the sip invite, or is 
another human going to do that? If its the former, then you need more 
things than just SDP mirroring. You would need a way for an automated 
answering of the call. That has all kinds of interesting security 
issues; being able to send someone a message that causes them to 
automatically answer calls can be troubling and used as a source of dos 
attacks (consider a phone with a single line).

If you assume that there is a human that will answer the phone acting as 
the mirror, what is the need for actually mirroring the media? Isn't it 
enough to merely receive some kind of media, and you can collect 
statistics from the RTCP? Why isn't someone saying 
"testing-1-2-3-testing" sufficient?

So, at a high level, I still don't understand the specific diagnostic 
problem which this is attempting to solve. I think you need to 
articulate that as a problem statement and requirements in order for the 
group to evaluate it better.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com