Subject: RE: [SIP] FW: I-D ACTION:draft-levin-sip-for-video-00.txt

From: Orit Levin <[email-masked]>
Date: Mon, 26 Mar 2001 16:37:11 -0500

Rohan!
Being in agreement with you in general, I sent the announcement to all three
mailing lists: SIP, MMUSIC and AVT.
Saying that, in interactive real-time communications, RTP/RTCP and SDP don't
stand on their own - they are tools being used by SIP to establish and
manage a session. Unless we find answers or define procedures, I have
temptation to declare that currently SIP, as a MULTImedia protocol, can be
used for simplistic symmetrical applications in ideal environment only.
While the extensions (for SDP and RTP/RTCP) and the new protocols (such as
SDPng) are being defined, SIP is the one that has to bind it all and define
interoperable procedures on session level.
Hope it clarifies the intension of the draft (and justifies its name ;-) ).

Orit.

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: Thursday, March 22, 2001 1:48 PM
To: Orit Levin
Cc: [email-masked]'
Subject: Re: [SIP] FW: I-D ACTION:draft-levin-sip-for-video-00.txt

Hi,

After reading the draft I concluded that this draft should be submitted 
instead to the MMUSIC WG and incorporated into the requirements document 
for SDPng.  I couldn't find anything in the draft which needed a SIP 
extension (only SDP and RTCP extensions).

[The only issue which we may have to address in SIP is the resolution of 
reINVITE glare takes too long, which is already an open issue]. Therefore 
I'd like to propose that we declare this off-topic for the sip list.

Some specific comments:

- 2.2.1 and 2.2.2 should be addressed in SDPng
- 2.2.3.1 (Skew transmission) sounds like a job for RTCP
- 2.2.3.2 can be solved using "flow-id" or SDPng
- 2.3 in SIP, the end systems should do this calculation, and can get the 
info they need using OPTIONS.  I'll point out that any endpoiunt capable of 
receiving more than one video stream should be able to calculate which 
codecs they can support simultaneously.
- 2.4.1 the reINVITE mechnism is the method for communicating midcall 
session changes in SIP.  As you correctly point out, expressing one stream 
of many should be addressed in SDP or SDPng (an issue of the session 
description body, not the SIP protocol).
- 2.4.2 currently the granularity of retry-after is in seconds, if the 
granularity is in milliseconds would this solve your problem?  If not, I 
think you need to prove that this is more important than a minor annoyance.
- 2.4.3 & 2.4.4   these are MMUSIC issues
- 2.4.5 & 2.4.6   these are AVT WG issues

thanks,
-rohan

At 11:22 PM 3/21/01 , Orit Levin wrote:

>-----Original Message-----
>From: Orit Levin
>Sent: Wednesday, March 21, 2001 12:26 PM
>To: SIP reflector (E-mail); [email-masked]'; [email-masked]'
>Subject: FW: I-D ACTION:draft-levin-sip-for-video-00.txt
>
>
>Hello all!
>You can find the attached draft in the IETF Draft directories.
>I am looking for the comments from all the interested parties on the
>emergency for each one of the listed (and additional) requirements before
>preparing proposal(s) for their resolution.
>
>There are some formatting deficiencies in the submitted ASCII version. I
>will be happy to send the Word version, for those who are interested.
>
>Best Regards,
>Orit Levin
>Chief Architect
>RADVISION Inc.
>TEL: +1.201.529.4300 x 230
>FAX: +1.201.529.3516
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Tuesday, February 27, 2001 6:53 AM
>Subject: I-D ACTION:draft-levin-sip-for-video-00.txt
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>         Title           : SIP Requirements for support of Multimedia and
>Video
>         Author(s)       : O. Levin
>         Filename        : draft-levin-sip-for-video-00.txt
>         Pages           : 14
>         Date            : 26-Feb-01
>
>This document outlines requirements for a call control
>protocol for real-time multimedia support over IP. As a
>part of its broader scope, the document examines
>important aspects of interactive video communications
>that need to be addressed by a call control protocol for
>real-time multimedia support and discusses techniques
>currently used to deal with them.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-levin-sip-for-video-00.txt
>
>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-levin-sip-for-video-00.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-levin-sip-for-video-00.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.
>
>_______________________________________________
>This list is for continuing development of the SIP protocol.
>The sip-implementor's list is the place to discuss implementation,
>and to receive advice on understanding existing sip.
>To subscribe to it, send mail to
>[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.