Subject: [MMUSIC] I-D ACTION:draft-ietf-mmusic-connectivity-precon-01.txt

From: [email-masked]
Date: Fri, 21 Oct 2005 10:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiparty Multimedia Session Control Working Group of the IETF.

	Title		: Connectivity Preconditions for Session 
                          Description Protocol Media Streams
	Author(s)	: F. Andreasen, et al.
	Filename	: draft-ietf-mmusic-connectivity-precon-01.txt
	Pages		: 18
	Date		: 2005-10-21
	
This document defines a new connectivity precondition for the Session
   Description Protocol precondition framework described in RFC 3312
   (and its update, RFC4032).  A connectivity precondition can be used
   to delay session establishment or modification until media stream
   connectivity has been verified successfully.  The method of
   verification may vary depending on the type of transport used for the
   media.  For reliable connection-oriented transports such as TCP
   verification is achieved by successful connection establishment.  For
   unreliable datagram transports such as UDP, verification involves
   probing the stream with data or control packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-connectivity-precon-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mmusic-connectivity-precon-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mmusic-connectivity-precon-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 27 Oct 2005 10:23:47 -0400

We completed Working Group Last Call on the -00 version of this document 
on 9/1, however subsequently, the authors felt that a couple of changes 
were warranted. In particular:

1) The -00 version desribed use of STUN/ICE and RTP No-Op for verifying 
connectivity for *datagram* transports and recommended that all 
implementations support RTP No-Op as the baseline mechanism. The -01 
changes that recommendation to ICE instead for the following reasons:
- RTP No-Op only works for RTP-based media streams, whereas ICE works 
for all types of media streams
- RTP No-Op is currently tied to be used only with one of the RTP 
feedback profiles ("*AVPF") which severely limits the applicability of 
it (we're trying to change that btw).
- Connectivity may be hampered by the presence of NATs and Firewalls, 
and RTP No-Op does little to address that. ICE however solves the problem.

The above implies that we currently have a normative reference to ICE 
and hence progress of connectivity preconditions will be tied to 
progress of ICE.

2) Clarified the procedures associated with using ICE for verifying 
connectivity. The updates were based on a pre-published version of ICE, 
which subsequently ended up changing. As a result of that, the current 
text in the draft is incorrect and will need to be updated 
(specifically, we need to move to the "valid" state instead of the 
"send-valid" state).

3) Added a paragraph about the relationship between verifying 
connectivity and ensuring you are actually verifying connectivity with 
the party you thought you were. For example, in NAT'ed environments, you 
may end up trying to exchange media with somebody else than you thought 
you were (as described in and solved by ICE). The draft now states, that 
connectivity preconditions only deal with verifying connectivity based 
on the address information exchanged. If you furthermore need to verify 
that you are actually communicating with the party you thought you were, 
then a correlation mechanism above and beyond connectivity preconditions 
will be needed. ICE provides such a correlation mechanism, and hence if 
the baseline recommendation is followed, the problem is solved anyway 
(but note that this not a prerequisite for the connectivity 
precondition, which in particular is of importance to 
connection-oriented transports such as TCP).

Please let us know if you have any questions or comments on any of the 
above.

-- Flemming

[email-masked] wrote:

>-------------------------------------------------------------------------
>CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY
>-------------------------------------------------------------------------
>In order to maintain computing infrastructure integrity, Cisco Systems
>Enterprise Messaging Services and InfoSec teams have set a mail policy
>disallowing executable attachments in email.
>
>This message contained an executable attachment type that is prohibited 
>by this policy. The attachment has been removed from this message and 
>copied to quarantine by our systems. It will be held in quarantine for
>seven days in the event that the content needs to be retrieved.
>
>Please be aware many viruses attempt to look like legitimate email or 
>notifications from anti-virus systems. We will clearly mark a seperation
>between our notifications and the original email as follows:
>
>  "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY"
>
>For further reference information about viruses and email antivirus 
>efforts within Cisco, please visit:
>
>http://wwwin.cisco.com/it/ems/services/antiviral
>
>If your concern isn't addressed by the information in this notification 
>or the above web page, you may open a support request:
>
>http://wwwin.cisco.com/support/
>
>Select "Messaging", "Email-Related", "Mail Routing"
>
>Please include in the text of your case the following information:
>
>* Full headers of the message. Documentation on displaying the full 
>headers is available at this URL:
>
>http://wwwin.cisco.com/support/library/faqs/solution002471.html 
>
>* This unique quarantine identifier: j9LFFhVV006989
>
>If the matter is urgent, you may follow up by calling one of the below 
>referenced numbers. Please make every effort to provide the above 
>requested information via the support web tool prior to calling as it 
>will greatly aid the resolution of your issue.
>
>Americas:
>1 408 526 8888
>
>Asiapac
>+61 2 8446 8888
>
>EMEA
>+31 20 485 4888
>
>Japan
>+81 3 5549 6888
>
>US (Toll Free)
>1| 800| 888| 8187| (ext.68888)
>
>Thank you for your cooperation,
>
>Enterprise Messaging Services
>Cisco Systems, Inc
>  
>
>------------------------------------------------------------------------
>
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>  
>